Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are button html tags outside of a form valid?

Tags:

html

forms

button

I just noticed that, in soundcloud, the "action" buttons on a track (like, repost, etc...) are all html button tags. Moreover, they are neither inside a form nor they bind to a form a la html5 nor submit a form (they apparently are being handled through javascript). Is this valid HTML? Can a button exist without a form? Or does that just make these buttons plain clickable divs? And how valid/unvalid would that be for screenreaders?

like image 393
ChuckE Avatar asked Jan 22 '13 15:01

ChuckE


People also ask

Does an HTML button have to be in a form?

A button element is valid anywhere in the document body where text-level markup may appear. Such an element need not have any relationship to a form element.

Do buttons need to be inside form?

Yes, structurally the submit button needs to be inside a form element for the document to be valid X/HTML.

Can a button be in a form?

The button can be created inside or outside the form. It can be styled in different ways using CSS. The <button> tag has many attributes, which gives desired features to the button. The form attribute of <button> tag is used to create a button that belongs to one or more forms in HTML.


1 Answers

A button element is valid anywhere in the document body where text-level markup may appear. Such an element need not have any relationship to a form element. The currently authoritative reference is the HTML 4.01 specification, and the formal rules are in the DTD, but you can take a shortcut and use the W3C Markup Validator to check whether a document is valid.

When not associated with a form, a button element is not very different from a span element (rather than div, which is block-level by default), but button has special default rendering. Browsers and assistive software may treat button as otherwise special too, and it is safest to use button only for elements that are supposed to trigger some action when clicked on. Conversely, such elements are often best represented using button markup, though you can create visually button-like elements in other ways too (images or CSS, mostly).

Outside a form, a button element has type=button as default (and that’s normally the only sensible type for it then). This means that it can only have an effect via JavaScript. This does not make it invalid in any way. However, you may consider generating such buttons via JavaScript instead of having them as static HTML content, so that when scripting is disabled, there won’t be a (valid, but) confusing button that does nothing.

To address clarifying questions in the comment below:

A button type=button element is similar to input type=button; the difference is that the latter has no content but takes the text shown in the button from the value attribute, whereas button has content that can be “rich” (with markup).

For either element, if using them causes a server action (typically, via an Ajax call), then we can indeed ask how the page works with JavaScript disabled. But this question might be irrelevant (perhaps the page is an application that is supposed to run with JavaScript anyway), and in any case there is nothing formally wrong with the idea.

Why do they exist? For author convenience and for legacy reasons, I would say. Similarly, one might ask why HTML has event attributes at all, when they cannot possibly work without client-side scripting and you can assign event handlers to elements in JavaScript. But in the early days, that was not possible, and even at present, it might be more convenient to use the button element or the onclick attribute than to do things in JavaScript (and, for making an element look like a button, CSS). There is also the point that button and input type=button create browser-dependent appearance for elements, and it might be argued that for most users, anything that has the style of his browser’s default style for buttons is perceived as a button.

like image 161
Jukka K. Korpela Avatar answered Sep 22 '22 10:09

Jukka K. Korpela