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?
相关问题
- Views base64 encoded blob in HTML with PHP
- Laravel Option Select - Default Issue
- Is there a way to play audio on a mobile browser w
- HTML form is not sending $_POST values
- implementing html5 drag and drop photos with knock
Yes. Since a very long time.
From whatwg.org :
In the era of ajax, most inputs aren't just send by submitting a form. And most buttons are just used to execute an action on click while using a recognizable widget.
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 aform
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 aspan
element (rather thandiv
, which is block-level by default), butbutton
has special default rendering. Browsers and assistive software may treatbutton
as otherwise special too, and it is safest to usebutton
only for elements that are supposed to trigger some action when clicked on. Conversely, such elements are often best represented usingbutton
markup, though you can create visually button-like elements in other ways too (images or CSS, mostly).Outside a form, a
button
element hastype=button
as default (and that’s normally the only sensibletype
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 toinput type=button
; the difference is that the latter has no content but takes the text shown in the button from thevalue
attribute, whereasbutton
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 theonclick
attribute than to do things in JavaScript (and, for making an element look like a button, CSS). There is also the point thatbutton
andinput 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.