Skip navigation
Tyssen Design — Brisbane Freelance Web Developer
(07) 3300 3303

Buttons: forgotten and immobile

By John Faulds /

Last year, Nick Cowie created a podcast on the button and how it is the "forgotten element". Well, it seems that it is not only developers who have forgotten about it, but browser makers, or more specifically those making browsers for handheld devices, and the Open Mobile Alliance (OMA) (authors of the XHTML-MP specification) who have forgotten about it as well.

 

As Nick points out in a more recent post, Time to stop using the button element, it seems that the button element is not part of the XHTML-MP specification (PDF, 400K) which is a shame because as I wrote last year, and more recently by Kevin Hale of Particletree, buttons provide you with more styling flexibility than inputs and you can do some cool stuff with them.

But is the lack of support for the button in XHTML-MP a real reason to stop using it as Nick suggests? The fact that the button is often overlooked by most developers anyway means that its use 'in the wild' is probably quite limited. But for those who do use it, should they be worried and thinking about reworking the code of all their sites?

Some might immediately dismiss the notion because "no-one uses handhelds to browse the Internet anyway." Again, Nick Cowie presents compelling reasons why this assumption is out of date and the situation is changing fast in The Mobile Web - Why should you care? in detail with indications that "by 2010 mobile internet users will exceed PC internet users". That's just three years from now! While predictions of this sort might be unrealistic, the overall trend in that direction can't be ignored.

So mobile browsing is here to stay and it's going to be big, but coming back to the humble button, are these possible developments any real reason to be changing mark-up or relegating certain elements to the 'recycle bin'?

In outlining four different approaches to mobile development, Cameron Moll points out that:

Methods that rework only the aesthetics of a site merely to fit it on a small screen likely fail to address the content-, context-, and feature-specific needs of mobile users.

which means that rather than reworking your site for mobile users, that you should offer an alternative site for them which is what the introduction of the .mobi Top Level Domain (TLD) is about. (It should be pointed out that the W3C doesn't favour this approach.)

If you subscribe to this view that the mobile user's experience is that much different from a desktop user's that they shouldn't be receiving the same content, then you don't necesssarily have to ditch the button from the desktop version of your sites. For instance, you could decide to use scripting to serve up different templates to mobile users and part of those template changes might include different form elements, or you could decide that many of the forms on your site aren't really relevant to the mobile user's experience anyway.

As Cameron points out, these decisions will vary from project to project and there doesn't appear to be a single correct approach for 'mobilising' your sites.

Something else to consider is, if XHTML-MP is to truly mean that "the same technologies can now be used to develop both the web and wireless version of your Internet site", (Developers' Home) maybe the button element should be included in any further updates to the DTD. XHTML-MP 1.1 was released in October 2006 and work on version 1.2 is in progress, so it's possible that new elements could be introduced just as is being proposed with HTML5.

While I can think of good reasons why XHTML-MP might include additional features not available to desktop users that make browsing easier for mobile users, I can't think of any good reasons why standard HTML elements should be ommitted particularly when other form elements like fieldset and optgroup are included. But then, designing for mobile devices is territory that is fairly unfamiliar to me, so perhaps someone else knows the answer to this and other questions raised in this post.