Check Boxes and Radio Buttons Conquered by DHTML

Philip Howard writes "Pretty much every form element has been conquered by CSS so far, letting us create stylish, integrated forms to tie in closely with our site designs for that UI polish graphics artists love to have. Radio Buttons and Check Boxes, however, have resisted most attempts to style them consistently, accessibly and elegantly- perhaps because nobody cares enough to come up with the solution. However, these elusive form elements have finally been conquered with a simple combination of CSS and Javascript and a little HTML wrapper. The solution is easy and quick to implement, is accessible (working with tab and space) and elegantly degrades where CSS and/or XHTML is not available."

Comments

Not really new, but interesting

[AKAImBatman]

In reading TFA, it seems that the author hasn't done anything actually new. He's just inserting styled DIV tags with click handlers attached to them. His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)

His solution is very similar to what mine would be. I'd just walk the DOM looking for checkboxes, then replace them with some inline element creation code. His solution is to get a list of all links, then find any with a special class. He then goes on to replace the contents of the links via the innerHTML property. Clunky, but it does work.

To the author: You can achieve your goal much more easily by attaching the className to the checkbox directly. Use getElementsByTagName to get a list of INPUT tags, then loop through those. When you find one you want to replace, use the

document.createElement()

function to build the replacement tag on the fly. You can then use

checkbox.parent.replaceChild(newCheckbox, checkbox)

to swap out the tags in a hurry.

Oh, and using an anchor tag for event handling is very 1990's. Try doing something like this instead:

newCheckbox.onclick = function(e) {
toggleCheckbox(newCheckbox, '', 'StyledCheckbox'+checkboxIndex+')
};

Note that you don't actually need the "StyledCheckbox" name, because you would be passing the actual element through to the event handler.

Good luck on your work. :-)

Re:Not really new, but interesting

[hacker]

"His primary concern (and what he believes he's invented) is a method to be backward compatible with browers that have JavaScript turned off, and/or browsers that lack CSS support. (You actually want to support those guys?)"

Yes, you most certainly do.

• Cellphones, pagers, "always-on" mobile Internet devices
• PDAs and handhelds, handheld browsers
• Devices for the blind, text-to-speech readers
• WAP devices
• Screen scrapers
• RSS syndication

If CSS delivers the style, and the HTML still delivers the content, then those will continue to work.

Once you start using Javascript or CSS to deliver the CONTENT, then you're doing something wrong, and breaking lots of your visitors.

Many Flash developers don't seem to understand this either (modulo the huge list of problems with using Flash). HTML should deliver the Flash, not the reverse.

Re:Not really new, but interesting

[Shaper_pmp]

"Why is it that amongst web developers there is only considered to be 'one way to do things'."

My theory is that it's a combination of:

1. More complex up-front design considerations than many other development tasks - your code is written once, but should run perfectly (or degrade gracefully) on every browser for every operating system for every architecture it ever runs on. In the website design community we deal every day with headaches caused by bugged or incompatible-by-design APIs, sketchy standards support and incredibly customisable interfaces (what's the C/C++/Java equivalent of "disable stylesheets", eh?). When you find a technique that works perfectly/degrades well on all known implementations, you stick to it like glue, and disseminate the word so others don't have to rip their own hair out. CSS tricks are even more slavishly followed, because so many rely on precise, back-engineered quirks of different browsers' rendering algorithms.

2. A large segment of much less-educated community participants. A lot of web designers (even now) have come at it from a graphic design background, and fail to appreciate the complex requirements and difficulties inherent in javascript, XHTML, CSS and how they all interact. Solving a lot of common problems with one approach which can be copied by the less-knowledgeable is a big win when it stops people re-inventing the wheel (and making it square - Flash developers, I'm looking at you).

3. Look where pandering to IE/Netscape and coding to browser quirks got us in the 90s - sometimes it took longer to make a site work acceptably in all browsers than it did to design and implement the first complete version! Quite often these days you'll find the "one way to do it" is basically conforming to the standards, avoiding proprietary extensions and writing pages which validate. There's nothing wrong with it, it encourages browser-manufacturers to conform to the standards, it simplifies the job of the web designer/developer and it doesn't restrict creativity one jot.

"Standards compliance is a good guideline, but it is not law."

No, but it is the only thing that stops you unnecessarily spending twice as long on a job coding to browser quirks. And it does ensure that everyone will be able to at least see the information, even if it's not necessarily pretty (pretty is easy too, for a further small investment of time). And it does mean you can tell the difference between a skilled, professional webmaster and someone's kid nephew with a copy of Frontpage.

"Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA."

Then, with apologies, you fail to understand the fundamental nature of the web. The whole point of the web is that anyone should be able to access information (and web apps count as information), however they like.

"Not expecting" customers to use different browsers only shows that you're closed-minded or not very imaginative (especially for someone posting on Slashdot!). "I didn't expect it" is a pathetic justification when something doesn't work unnecessarily, and indicates a lack of professionalism in your execution.

"Not desiring" it (eg, coding to a specific browser as my company does - I don't) means you're effectively locking yourself and your customers into one company, and everyone knows vendor lockin is a pointless risk - even Microsoft's now paying lip-service to interoperability.

"Yet, people wear their xhtml compliant gif's like medals of honor."

Yes. They're proudly saying "Look - I'm a professional". Or "I care about doing things The Right Way". Or even "Fuck off browser-makers, unless you can make it work according to the standards". How are these a bad thing?

"Write your pages with compliance in mind, but never lose site of refining your apps and pages for your tar

Re:Not really new, but interesting

[poot_rootbeer]

I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA.

I, as a user, expect the web apps I use to be usable from any web browser available to me, including cellphones and PDAs.

If your company will not provide this ability to me, I will visit your competitors and see if they will.

Re:Not really new, but interesting

[pocopoco]

>Yes, I'm a purist like that.

Anyone else find it amusing that these "purist" people haven't even read the official specification? It's clearly stated at http://www.w3.org/TR/xhtml1/ that you are allowed to send XHTML 1.0 (which is what most sites are using) as text/html and they even give you an appendix full of compatibility tips when doing so.

Re:Not really new, but interesting

[FlynnMP3]

Name one.

Homestar Runner

Is it pleasant to use? Meh. Depends on your web eccentricity. The site itself is pretty easy and fun.

Flash has it's place, and some flash designers know the good uses, but others just need to beat on the head with a web standards stick.

-FlynnMP3

Re:Not really new, but interesting

[ubernostrum]

Anyone else find it amusing that these "purist" people haven't even read the official specification?

Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML. Of course, that "compatibility" is imposed by fiat, not by any actual compatibility of the XHTML and SGML-based HTML syntaxes. There are actually some important incompatibilities even if all the guidelines in Appendix C of the XHTML 1.0 spec are followed. But I'm sure a "purist" like yourself has read up on that, right?

And I'm not just talking about problems with XHTML's minimized tag syntax conflicting with SGML's SHORTTAG. For an example, consider the example of point 1 in the HTML Compatibility Guidelines. It says, in part:

Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

Sounds nice, but it's wrong and can actually lead to well-formedness errors which will be detected by strict XML parsers. This is because any text/* media type, when sent with an HTTP Content-Type header which did not include the charset parameter, is defined as being encoded in US-ASCII. So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document. Whoops. For added fun, note that this problem crops up when you send text/xml, too; the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml, because then RFC 3023 will mandate those to be the default encodings.

Not the first time, but nice idea

[hedgehog2097]

This is not the first time check boxes and radio buttons have been "conquered".

boo.com had quite groovy code if I remember rightly.

Suggestion to improve your version: onFocus="blur(this)"

are they really blinky for anyone else?

[pezpunk]

granted i'm not exactly running the latest hardware, but every click on a radio button seemed to illicit a lot of blinking and flashing on the part of the other buttons. maybe it's just javascript running slowly as the DIVs move around or something, but i prefer to think of it as simple jealous from the other buttons in that group. "click me instead!" "no me!"

in any case, i'm all for flashy design, but this seems to be more trouble and more cumbersome than it's worth, unless that javascript can be optimized to not be so slow.

Usuability standards

[AtariAmarok]

"The main focus however should be making sites that follow standards so they are viewable on every type of browser and platform."

Not just that; there are usability standards. Checkboxes and radio/option buttons are supposed to look and act a certain way. It makes using them that much easier. Disguising them as something that looks like Lucky Charms marshmallows really fudges matters. The sample even had checkboxes made to look like option buttons (round).

Works with space and tab?

[matth]

OR NOT.. using Mozilla... when I hit space it checks it and ALSO moves me to the next page!!! Not how it is suppose to work.

Re:Accessible?

[senocular]

Firefox (Win) seems to have no trouble tabbing through them.

Re:Accessible??

[AttilaSz]

My results:

IE6: space and enter can't push the button
Opera8 (my primary browser): tab can't select the button.

Sheesh...

Re:Accessible??

[Anonymous Coward]

I'm using Firefox/1.0.4/Linux and I don't get the same semantics when using Javascript or not. If I'm not using Javascript (no cute inputs) I can change the state using the space bar and I can submit using Enter. But, if using Javascript spacebar moves a page down changing the input state and enter just changes the state but doesn't submit the form.

gmail...

[Fusen]

isn't this the same as what gmail uses, and that's been out for quite awhile now.

Not Conquered!

[AutopsyReport]

Unfortunately for the author, this page renders terribly in Internet Explorer 6. Anytime I hover over the checkboxes or radio buttons, the graphics momentarily dissapear. I can even manage to get two checkboxes beside each other to dissapear by aligning the mouse in the middle. Not good.

However, it renders fine in Firefox. Nevertheless, when it's not compadible with Internet Explorer, I'd hardly call this issue conquered.

Re:Accessible??

[Sentry21]

This fails also in Safari - the first tabbable element on the page is the button. Shift-tabbing up from that lands me in the tab (as in tabbed-browsing) area.

Ten points for style, but minus several million for accessibility.

Re:Somebody please "conquer" the FILE input elemen

[Anonymous Coward]

There is a way to do this, although it's a bit of a hack. Basically you make a separate text element, and an image for a button. You make your actual file control invisible (using opacity of 0 in all its different variants, NOT using visibility or display) and position it using CSS so that the button is over the image (it helps to use a 50% opacity for this step). Then you put javascript in the onchange event of the file box that updates the other text field so the user can see that they've selected a file (although the other text field doesn't have to post back to the server).

Bold Text Conquered By HTML

[jhamm]

"Now, there's an easy way to make text bold on a webpage. Just enclose it with ! It's also backwards-compatible, showing normal text on browsers (such as Lynx) that don't support bold text." Why is this a Slashdot article? Hasn't anyone heard of webfx.eae.net?