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

[hacker]

"There is nothing more annoying than browsing to a site from a machine which doesn't have flash installed (don't want it) and realizing the site was written in such a way as to not be able to get past the into animation without flash."

I'll give you some more fuel to pour on that fire:

1. Can't change contrast (for those who might be colorblind and can't see light grey text on a white background. Who taught these kids color theory anyway? Barney the dinosaur?)
2. Can't change font size (whaddya mean you can't see my 6 point fonts, what are you, blind?)
3. No ability to search the text of a flash page using standard browser "Find" functions (yes, some search engines can index Flash now, with the proper hooks into the Macromedia Flash SDK, but its not exposed on the user end)
4. No fallback for non-Flash browsers, built into the Flash itself

It irritates me too, so I just don't use it, or recommend sites that do. Let's just make our entire site in PostScript, or better yet an OpenOffice.org .sxw or an OpenDocument .odp file format.

"Why not? You don't have the right plugin? Oh, too bad... get with the times!"

</sarcasm>

"People who make web-sites which can't be operated without flash need beatings."

People just need beatings anyway, just to let them know they can be beaten by anyone for any reason. This whole "Gimme" generation and the new business model of "Don't have a viable business plan? Sue someone! Profit!" needs to stop.

I'm going to have to start a new campaign called "Slap the Stupid out of Everyone" that does just that. Can't count change in the drive-thru? Find a new job, you're fired. Can't figure out how to answer questions about your product in the store? You're fired. Parking like an idiot? Towed.

I'm tired of just ignoring and tolerating stupidity and ineptitude and excuses. It has to stop.

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

The real question is

[Rosco P. Coltrane]

Will Lynx render them correctly with ascii-art?

Check Boxes and Radio Buttons Respond:

[Anonymous Coward]

This occupation won't stand! You may think you can apply your western styles upon us by force, but history will prove you wrong.

Spiffy

[generic-man]

The examples look very nice. I still think the bigger problem is that web applications have absolutely no UI consistency between them, though. On one web site, select-boxes cause a form to be immediately submitted when a selection is made; on others, you have to click "Go." On one web site, check boxes look like boxes with check marks; on another they look like stars; on another they look like glowing orbs (not very colorblind-friendly).

This is the sort of thinking that leads to such UI atrocities as Winamp, iTunes for Windows, and Firefox for Mac OS X: all three of these ignore most of the native widget drawing capability in the name of creating a pointlessly slick, cross-OS-consistent experience.

I for one welcome the arrival of XAML and XUL: ways to describe forms that every OS will render using its own navigation and widget capabilities. It'll be as awesome as the time Java solved that problem for everyone everywhere.

Re:Fucking graphic design majors

[RosenSama]

I don't agree with this in two different ways.

#1 "new and better are mutually exclusive"
You are saying there is no way to improve UI. If new (change) is mutually exclusive with better than then only thing left is old (unchanged). Without change, there's no way to get better leaving a permanent status quo. By adhering to these arguments we'd still have rotary phones, analog clocks, and the command line.

#2 They didn't introduce a new UI element, they just learned how to make existing ones match the page.