More about the <button> element

A follow up to my previous post on the button element

A little history

The button element was introduced with HTML 4, to quote the w3c press release:

A BUTTON element whose type is “submit” is very similar to an INPUT element whose type is “submit”. They both cause a form to be submitted, but the BUTTON element allows richer presentational possibilities.

Why almost nobody use the button element

Two possible answers, either they choose not to use it or do not know about

Choosing not to use the <button> element

Seeing almost every browsers support HTML4 and the <button> element (some a little differently to others, see below), at least you have control of how <button type=”submit” > looks over <input type=”submit”> on some browsers. The only logic I can see for not using the <button> element is that form creators, do not want to confuse users by using buttons that differ from the default setting of user’s browsers. While I can see this view being supported by the likes of Jakob Nielsen, I can not see the majority of web designers avoiding the opportunity to make use of the richer presentational possibilities offered by the button element for styling.

Not knowing about the <button> element

I would suggest that most form creators learnt about forms prior to HTML 4 or learnt (including view source) from someone who did. So the have always used <input type=”submit”> and accepted the limitations and various browser manufacturers ideas on what I button should look like. Well I suppose this is the start of a campaign to educate form creators there is a alternative.

Fun with Internet Explorer

In addition to IE on PC adding the extra margin. Another interesting feature of IE on PC is unless told otherwise, IE on a PC fixes the font size of the button and all elements contained within to the default font size in pixels. If you are using relative font sizes (ie elastic design) this works fine at medium, but does not allow the buttons to scale at different setting. This can be resolved by adding the following declaration to the stylesheet: button { font-size: 1em; } .

Lozenges of Death

Well that is what one of my colleagues referred to my previous efforts as. So here are another pair of buttons, which I will be using in a forthcoming project.

Stylish Accessible Buttons Two

Added December 26: Lea I did test in Safari, however it was before I made the corrections for IE on a PC, and it was then I forgot that Safari behaves like IE when you use the !important hack inline. It should be fixed now.

6 Responses to “More about the <button> element”

  1. Lea de Groot Says:

    Probably want to check those buttons in Safari before you go live – the icon is overlapping the words :(
    Looks fine in Mac/FF, of course :)

    I must admit that I don’t use Buttons, principally because I didn’t know what an appropriate usage was; I shall experiment with them next time I do a form (oh, look, thats scheduled for sometime next week :))

    Lea

  2. Kay Smoljak Says:

    I fall into the category of not really knowing about the button element (at least until I read this). Thanks Nick for edja-ma-catin’ me!

  3. Lea de Groot Says:

    Ah, much better :)

  4. Nick Cowie » I am doing a presentation Says:

    […] The advantage of doing a presentation on the button element, which are the most popular posts on this blogs, is I have already done most of the research for those posts: Stylish Accessible Buttons, More about the button element and a half written post about how to position buttons. So there is very little work to do, except try and find out how IE7 beta deals with the button element and exactly what extra padding IE5 and IE6 adds to the button element, it is not as I previously stated a fixed amount but appears to be proportional to the width of the button element. Still all of this can be packaged into a 30 minute presentation, as long I only briefly touch on conditional comments for serving an additional stylesheet to IE and how to use absolutely position an element inside a relatively positioned element. […]

  5. adrian Says:

    On Safari 2.0.4, it seems like BUTTON elements are not included in the forms.elements collection. Has there been a fix to this?

  6. RE Mogul Says:

    Buttons should be usable, without the ability to read their text.

    For example, the button I clicked to post this was obvious.
    It submits. It is the only one. What else would it do?

    If you asked me later, I wouldn’t be able to tell you what it actually read. I can easily discern its function from context. Focus on context.

    Everything else is simply diversion, in regards to accessibility.

    :::::::::CODING for the KEYBOARD:::::::::

    IN THE PERFECT WORLD:
    All developers design keyboard-friendly interfaces.

    Case in Point:

    Keyboard a submit button, make it read:

    [SHIFT] [ENTER] to Submit.

    Notice the shift-enter convenience.
    Try it. It just feels right.
    Use actual keyboard button images.

    It would make for a super-large button — an EZ target.

    Precision-pointing is the most difficult thing one can ask of a user.
    Need Proof? Program a robot to point and click a virtual button. Then program a robot to shift-enter. Then tell me which is the EZiest task.

Google