«

I see various sites that use <button>s with attached onclick events to
perform some action if the button is clicked. But these particular sites
don't have these buttons as form controls - they are not submitting a
form and want a button so they use it. This seems to work, but is it
defined behaviour? Is it reliable cross-browser?

All these buttons were like this:

<button id='abc'>sometext</button>

but with no <form> anywhere. I tried using a cut-down version of the
page for some testing and was bitten by being too good and putting a
<form> around the buttons without remembering what the default type of a
button is in a form.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

On Fri, 18 Nov 2011 21:57:44 +0000, Tim Streater wrote:

> I see various sites that use <button>s with attached onclick events to
> perform some action if the button is clicked. But these particular sites
> don't have these buttons as form controls - they are not submitting a
> form and want a button so they use it. This seems to work, but is it
> defined behaviour? Is it reliable cross-browser?

I don't think any user input elements have had to be wrapped in a form
since at least HTML 4.01.

It should be reliable if you use a valid doctype that supports the
functionality. Unless someone is using a browser that doesn't support
that doctype of course.

Ch 17 (Forms) of the 4.01 specification includes the paragraph:

The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration when
they are used to build user interfaces. This is discussed in the section
on intrinsic events. Note that controls outside a form cannot be
successful controls.

To clarify that last sentence, from elsewhere in the same chapter:

A successful control is "valid" for submission. Every successful control
has its control name paired with its current value as part of the
submitted form data set. A successful control must be defined within a
FORM element and must have a control name.

Rgds

Denis McMahon

Rgds

Denis McMahon

2011-11-19 0:53, Denis McMahon wrote:

> I don't think any user input elements have had to be wrapped in a form
> since at least HTML 4.01.

Do you mean that you were too lazy to check this out, or didn't know how
to do that?

> It should be reliable if you use a valid doctype that supports the
> functionality.

You have no idea of HTML, do you?

> Unless someone is using a browser that doesn't support
> that doctype of course.

That's what I thought, no clue.

> A successful control is "valid" for submission.

So what does it matter if it's not within a form element?

Hint: It cannot have any functionality unless client-side scripting is
enabled. Does this ring a bell, anywhere?

--
Yucca, http://www.cs.tut.fi/~jkorpela/

On Sat, 19 Nov 2011 01:14:53 +0200, Jukka K. Korpela wrote:

> 2011-11-19 0:53, Denis McMahon wrote:
>
>> I don't think any user input elements have had to be wrapped in a form
>> since at least HTML 4.01.
>
> Do you mean that you were too lazy to check this out, or didn't know how
> to do that?

I mean I know that 4.01 doesn't require input, button, select, or textarea
to be wrapped inside a form block, I'm not sure about 3.2 and 2.0, but I
do remember that in some incarnation, html when I started using it did
require that input elements were inside form blocks. That was back in
about '96.

As I've recently been bitten by discrepancies between what tidy considers
the right doctype for 3.2 and what w3c unicorn considers the right
doctype, I'm limiting what I say to what I know, namely that from html
4.01 onwards, you don't need to wrap "input" type elements in a form.

>> It should be reliable if you use a valid doctype that supports the
>> functionality.
>
> You have no idea of HTML, do you?

Yes. We're talking, as far as I am aware, about the markup here.

>> Unless someone is using a browser that doesn't support that doctype of
>> course.

> That's what I thought, no clue.

It's possible that someone somewhere out there is using a version of of
eg netscape that is so old that it doesn't recognise eg xhtml 1.x, or
even html 4.01.

Such a browser might actually break on an input element type that wasn't
wrapped in a form block, I have very vague recollections of one of the
early netscapes doing exactly that on a few occasions when I first
started writing html.

>> A successful control is "valid" for submission.
>
> So what does it matter if it's not within a form element?
>
> Hint: It cannot have any functionality unless client-side scripting is
> enabled. Does this ring a bell, anywhere?

As far as I can see, the op is discussing positioning of various elements
in the html, not any underlying scripting technologies.

Rgds

Denis McMahon

2011-11-18 23:57, Tim Streater wrote:

> I see various sites that use <button>s with attached onclick events to
> perform some action if the button is clicked. But these particular sites
> don't have these buttons as form controls - they are not submitting a
> form and want a button so they use it. This seems to work, but is it
> defined behaviour?

Basically yes. You can use the onclick attribute on almost any element
in the document body, including <button> elements of course. The only
vagueness is that the default for <button> is type=submit, making the
element a submit button. When there is no enclosing form, there can be
no form submission, so apparently this means that clicking on the
<button> element has no effect unless there's an event attribute. This
can be expressed by saying that outside a form, <button> has type=button
as the default.

> Is it reliable cross-browser?

Yes, to the extent that client-side scripting is reliable cross-browser.

> All these buttons were like this:
>
> <button id='abc'>sometext</button>
>
> but with no <form> anywhere.

Presumably the page has JavaScript code that assigns event handlers to
the elements, accessing them by the id attribute value

> I tried using a cut-down version of the
> page for some testing and was bitten by being too good and putting a
> <form> around the buttons without remembering what the default type of a
> button is in a form.

Yeah, that's nasty. I've been bitten too - even when writing code from
scratch. It's so easy to think that <button> has type=button as the
default. But in reality, if you want to create a "pure button" that does
not submit the enclosing form, you need to specify the attribute
type=button explicitly or write the onclick event handler so that it
ends with returning the value false (which causes the default action for
the element to be suppressed).

--
Yucca, http://www.cs.tut.fi/~jkorpela/

In article <ja7koo$m51$>,
"Jukka K. Korpela" <> wrote:

> 2011-11-18 23:57, Tim Streater wrote:
>
> > I see various sites that use <button>s with attached onclick events to
> > perform some action if the button is clicked. But these particular sites
> > don't have these buttons as form controls - they are not submitting a
> > form and want a button so they use it. This seems to work, but is it
> > defined behaviour?
>
> Basically yes. You can use the onclick attribute on almost any element
> in the document body, including <button> elements of course. The only
> vagueness is that the default for <button> is type=submit, making the
> element a submit button. When there is no enclosing form, there can be
> no form submission, so apparently this means that clicking on the
> <button> element has no effect unless there's an event attribute. This
> can be expressed by saying that outside a form, <button> has type=button
> as the default.

Good, thanks.

> > Is it reliable cross-browser?
>
> Yes, to the extent that client-side scripting is reliable cross-browser.
>
> > All these buttons were like this:
> >
> > <button id='abc'>sometext</button>
> >
> > but with no <form> anywhere.
>
> Presumably the page has JavaScript code that assigns event handlers to
> the elements, accessing them by the id attribute value

Correct.

> > I tried using a cut-down version of the
> > page for some testing and was bitten by being too good and putting a
> > <form> around the buttons without remembering what the default type of a
> > button is in a form.
>
> Yeah, that's nasty. I've been bitten too - even when writing code from
> scratch. It's so easy to think that <button> has type=button as the
> default. But in reality, if you want to create a "pure button" that does
> not submit the enclosing form, you need to specify the attribute
> type=button explicitly or write the onclick event handler so that it
> ends with returning the value false (which causes the default action for
> the element to be suppressed).

Probably safest to do it under all circumstances.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689