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.

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.