More about the <button> element

A fol­low up to my pre­vi­ous post on the but­ton element

A little history

The but­ton ele­ment was intro­duced with HTML 4, to quote the w3c press release:

A BUTTON ele­ment whose type is “sub­mit” is very sim­ilar to an INPUT ele­ment whose type is “sub­mit”. They both cause a form to be sub­mit­ted, but the BUTTON ele­ment allows richer present­a­tional possibilities.

Why almost nobody use the button element

Two pos­sible answers, either they choose not to use it or do not know about

Choos­ing not to use the <but­ton> element

See­ing almost every browsers sup­port HTML4 and the <but­ton> ele­ment (some a little dif­fer­ently to oth­ers, see below), at least you have con­trol of how <but­ton type=“submit” > looks over <input type=“submit”> on some browsers. The only logic I can see for not using the <but­ton> ele­ment is that form cre­at­ors, do not want to con­fuse users by using but­tons that dif­fer from the default set­ting of user’s browsers. While I can see this view being sup­por­ted by the likes of Jakob Nielsen, I can not see the major­ity of web design­ers avoid­ing the oppor­tun­ity to make use of the richer present­a­tional pos­sib­il­it­ies offered by the but­ton ele­ment for styling.

Not know­ing about the <but­ton> element

I would sug­gest that most form cre­at­ors learnt about forms prior to HTML 4 or learnt (includ­ing view source) from someone who did. So the have always used <input type=“submit”> and accep­ted the lim­it­a­tions and vari­ous browser man­u­fac­tur­ers ideas on what I but­ton should look like. Well I sup­pose this is the start of a cam­paign to edu­cate form cre­at­ors there is a alternative.

Fun with Internet Explorer

In addi­tion to IE on PC adding the extra mar­gin. Another inter­est­ing fea­ture of IE on PC is unless told oth­er­wise, IE on a PC fixes the font size of the but­ton and all ele­ments con­tained within to the default font size in pixels. If you are using rel­at­ive font sizes (ie elastic design) this works fine at medium, but does not allow the but­tons to scale at dif­fer­ent set­ting. This can be resolved by adding the fol­low­ing declar­a­tion to the stylesheet: button { font-size: 1em; } .

Lozenges of Death

Well that is what one of my col­leagues referred to my pre­vi­ous efforts as. So here are another pair of but­tons, which I will be using in a forth­com­ing project.

Styl­ish Access­ible But­tons Two

Added Decem­ber 26: Lea I did test in Safari, how­ever it was before I made the cor­rec­tions for IE on a PC, and it was then I for­got that Safari behaves like IE when you use the !import­ant hack inline. It should be fixed now.

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

  1. Lea de Groot Says:

    Prob­ably want to check those but­tons in Safari before you go live — the icon is over­lap­ping the words :(
    Looks fine in Mac/FF, of course :)

    I must admit that I don’t use But­tons, prin­cip­ally because I didn’t know what an appro­pri­ate usage was; I shall exper­i­ment with them next time I do a form (oh, look, thats sched­uled for some­time next week :))

    Lea

  2. Kay Smoljak Says:

    I fall into the cat­egory of not really know­ing about the but­ton ele­ment (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 advant­age of doing a present­a­tion on the but­ton ele­ment, which are the most pop­u­lar posts on this blogs, is I have already done most of the research for those posts: Styl­ish Access­ible But­tons, More about the but­ton ele­ment and a half writ­ten post about how to pos­i­tion but­tons. So there is very little work to do, except try and find out how IE7 beta deals with the but­ton ele­ment and exactly what extra pad­ding IE5 and IE6 adds to the but­ton ele­ment, it is not as I pre­vi­ously stated a fixed amount but appears to be pro­por­tional to the width of the but­ton ele­ment. Still all of this can be pack­aged into a 30 minute present­a­tion, as long I only briefly touch on con­di­tional com­ments for serving an addi­tional stylesheet to IE and how to use abso­lutely pos­i­tion an ele­ment inside a rel­at­ively posi­tioned element. […]

  5. adrian Says:

    On Safari 2.0.4, it seems like BUTTON ele­ments are not included in the forms.elements col­lec­tion. Has there been a fix to this?

  6. RE Mogul Says:

    But­tons should be usable, without the abil­ity to read their text.

    For example, the but­ton I clicked to post this was obvi­ous.
    It sub­mits. 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 actu­ally read. I can eas­ily dis­cern its func­tion from con­text. Focus on context.

    Everything else is simply diver­sion, in regards to accessibility.

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

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

    Case in Point:

    Key­board a sub­mit but­ton, make it read:

    [SHIFT] [ENTER] to Submit.

    Notice the shift-enter con­veni­ence.
    Try it. It just feels right.
    Use actual key­board but­ton images.

    It would make for a super-large but­ton — an EZ target.

    Precision-pointing is the most dif­fi­cult thing one can ask of a user.
    Need Proof? Pro­gram a robot to point and click a vir­tual but­ton. Then pro­gram a robot to shift-enter. Then tell me which is the EZi­est task.

Affiliates

Google
text advertising by
Powered by Reseller Zoom