`button` Element

Skip to Page Content
Up, Next & Previous Links
Your Location
Main Menu
Page Footer

In this page:

Module
Description
#REQUIRED Attributes
Specific Attributes
Common Attributes
Content Model

Module

The button element is declared by the XHTML 1.1 Forms Module but is not present in the *W3C XHTML 1.1 Basic Forms Module

The button element allows the creation of buttons which may have richer content than buttons created using the input element. This is because input type="submit", input type="reset" and input type="button" elements may specify only plain text to be contained within the button, whereas the button element may contain other elements: this allows the inclusion of, for example, strong, img, object or br elements within the button. Although an input type="image" element allows an image to be used as a form submit button, the button element also enables both reset buttons and scripted push-buttons to contain images. Note, however, that image maps should not be used within button elements - a condition originating in the W3C Specification of the *HTML 4.01 BUTTON element.

Some very old browsers (e.g. Netscape 4) do not support the button element at all so if you are writing code which may need to be compatible with such legacy browsers you should not use the button element.

On form submission, the only button element within the form which should have a name=value pair sent to the processing URI is the button which was pressed by the user in order to submit the form (provided that it has been given a name attribute). The value sent should be the contents of its value attribute.

Note: If you are writing code which needs to be compatible with Internet Explorer, bear in mind that IE7 and below do not send the value of the value attribute for button elements, but rather the entire (X)HTML contents of the element itself! Also, for some reason, IE6 and below send name=value pairs for all button elements with name attributes, regardless of which one was pressed to submit the form, even sending pairs for type values of "button" and "reset". IE7 improves matters somewhat, sending a name=value pair only for the submit button which was actually used to submit the form. However, it also sends pairs for all button elements of type "button" which have been given a name attribute. IE8 in strict mode seems to behave correctly, sending a pair only for the submit button pressed, with the value being that of its value attribute.

A button element can contain both block-level and inline content. However, if you are placing a button element in a location where block-level elements are not allowed, e.g. within a p element, you should not include block-level content in your button.

Types of `button`

The button element with type="submit" is essentially just a richer version of the input type="submit" element and will submit the form to the processing URI. This is the default type of button so omitting the type attribute altogether is equivalent to specifying type="submit".

The button element with type="reset" is essentially just a richer version of the input type="reset" element and will reset all form controls to their initial values.

The button element with type="button" is essentially just a richer version of the input type="button" element and will create a push-button - such a button will require scripting to give it a function. Bear in mind, however, that user agents without scripting capability (or with scripting disabled) will present the user with a button which does absolutely nothing. This may be confusing if no explanation is provided. It is therefore probably best to create such buttons using the same scripting language as that which assigns the handler. Bear in mind, however, that some browsers don't allow a button's type to be changed using JavaScript, with some creating type="submit" buttons by default and some type="button" buttons. (This means that it is not possible to create a submit or reset button within JavaScript which will work cross-browser - although you can use input for this.) You can simulate a type="button" button (for those browsers which create a "submit" button by default and don't allow type to be changed) by always returning false from the onclick handler.

For example:

<button type="button" onclick="alert( 'Thank you!' );">
<strong>Please</strong><br />
Push Me!
</button>

This push-button renders as:

If your browser supports JavaScript and it is enabled, the above button should function correctly and thank you for pushing it! If you can view the HTTP Response Headers for this page (using, for example, the excellent *Web Developer Toolbar for *Firefox), you will find that I have added a Content-Script-Type header of "text/javascript" to this page so that the user agent is informed that the onclick attribute above contains JavaScript. In normal circumstances, however, all event handling code is best put in external scripts (and included using the script element) rather than by adding attributes from the Intrinsic Events Module to individual elements.

Using `button` Elements as Links

Although it is valid XHTML 1.1 to place a button element within an a element, it is not cross-browser compatible to make links out of buttons in this manner. Instead, you can create this effect by putting a form element around the button. The down side of this is that form elements are block-level elements (and must contain block-level content) so it is not possible to include such a link in an inline context - unless of course it is the only such link within a block, in which case the containing form element can surround the block instead of just the button. Bear in mind, though, that you can't put one form inside another form at any nesting depth - see Descendant Exclusions. Lastly, it is worth noting that not all browsers will give any advance indication as to the form's target URL in their Status Bar (as is standard for a conventional link when hovered over or in focus). A quick test of my two main Linux browsers shows that Opera 9.60 does but Firefox 3.0.6 does not.

For example:

<form action="http://www.google.co.uk/" method="get"><div>
  <button type="submit">Google</button>
</div></form>

This simulated button link renders as:

Padding Issues

In Internet Explorer, for reasons unknown, buttons with long text content are usually rendered with excessive horizontal padding - the longer the button text, the more excessive the padding. This annoyance can be avoided by using the CSS declarations width:auto; overflow:visible; and setting the padding property to the desired value.

#REQUIRED Attributes

There are no #REQUIRED attributes on the button element.

Specific Attributes

Specific attributes of the button element are listed below:

From the Forms Module - the Element's own Module

accesskey [ type Character ]

Key to be pressed which allows the button to be activated directly from the keyboard

disabled [ type Boolean ]

If this attribute is present, the button is initially disabled - no data is sent to the processing URI for disabled elements when the form is submitted. The user cannot interact with a disabled control.

name [ type CDATA ]

A name for the button. If the button type is "submit" (the default) and this button is the one activated in order to submit the form then this name is sent to the processing URI with the rest of the form data. The value sent (in a name=value pair) should be that of the value attribute. No data will be sent if the name attribute is absent.

tabindex [ type Number ]

An integer between 0 and 32767 specifying the position of the button in the tabbing order of the document

type [ type Enumeration (submit | button | reset) - default="submit" ]

The type of button to be created

submit: a submit button - a richer version of input type="submit"
button: a push-button - a richer version of input type="button"
reset: a reset button - a richer version of input type="reset"

value [ type CDATA ]

A value for the button. Unlike the case of input-based buttons, it is not used as the button text (the content of the button element is used instead). It is merely the value which should be sent to the processing URI along with the name attribute should the button be activated to submit the form.

From the Intrinsic Events Module

onblur [ type Script ]: Script to be executed when the element loses focus
onfocus [ type Script ]: Script to be executed when the element receives focus

Common Attributes

Common attributes of the button element are listed below:

From the Core Attribute Collection

class [ type NMTOKENS ]: One or more space separated classes
id [ type ID ]: A unique identifier for the element
style [ type CDATA ], from the Style Attribute Module (deprecated): Element-specific styles
title [ type Text ]: Descriptive title for the element (in some user agents this may appear as a "tooltip" when the mouse hovers over the element)
xmlns [ type URI - #FIXED 'http://www.w3.org/1999/xhtml' ]: XML namespace

From the I18N Attribute Collection

dir [ type Enumeration (ltr | rtl) ], from the Bi-directional Text Module: Left-to-right or right-to-left directionality
xml:lang [ type LanguageCode ]: A language code for the element

From the Events Attribute Collection

All attributes in the Events Attribute Collection are supported:
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup

Content Model

The Content Model for the button element is:

See Content Model & Nesting for information about Content Model syntax and Nesting Groups.

Valid children of `button`

#PCDATA
From the Text Module: abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1 - h6, kbd, p, pre, q, samp, span, strong, var
From the List Module: dl, ol, ul
From the Tables Module: table
From the Images Module: img
From the Presentation Module: b, big, hr, i, small, sub, sup, tt
From the Client-side Image Map Module: map
From the Scripting Module: noscript, script
From the Edit Module: del, ins
From the Bi-directional Text Module: bdo
From the Object Module: object

Note: A button element must never contain any of the following elements, at any nesting depth: input, select, textarea, label, button, form, fieldset. See Descendant Exclusions.