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

[Psychic Burrito]

So, in other words, the code is incompatible with text-only browsers that understand javascript, as the form element get replaced with pictures on display, making this solution pretty nice but not really very correct.

Re:Not really new, but interesting

[mattwarden]

Not only is it clunky, but it's incorrect. Classes are for CSS behavior, not JavaScript behavior. See: http://www.alistapart.com/articles/scripttriggers/

And, innerHTML is evil.

And of course you're right, this isn't new.

Re:Not really new, but interesting

[thirteenVA]

Here we go...

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

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

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.

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

Write your pages with compliance in mind, but never lose site of refining your apps and pages for your target audience, regardless of it if bends the standards.

Re:Not really new, but interesting

[gstoddart]

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.

This is my biggest problem with flash.

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.

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

Re:Not really new, but interesting

[MarkEst1973]

Is anyone really browsing the web from their cell phone? PDA? The resolution and functionality in these things are terrible. We have a decade of hard experience behind us building good web browsers. Let's build one into devices that want to surf the web.

The same goes for screenreaders. I have to make my applications Section 508 compliant everyday because we're a gov't contractor. It sucks. If Mozilla and IE know what elem.innerHTML is and can render it, why can a screenreader not work like a real goddamned web browser? Then it too would know what my elem.innerHTML is and can read it accordingly aloud to the non-sighted user.

There are real 508 problems for blind folks. Implementing a "skip nav" hidden link to bypass the multitude of primary navigation links is standard. If we can pass the user around the page like that, why not include more dynamic pieces in the page and present a non-visible menu for blind people? "Press 1 for My Profile, Press 1 for ... blah blah blah". As they press a button, *javascript and dhtml* take them around the page, reading more parts of the menu.

In my mind, a very accessible app would be more like a phone VRU to a blind person. But what's the problem? JAWS doesn't know shit about a page beyond html markup. It was only in the past few years that they managed to handle nested tables well. So blind people are lost when it comes to even Section 508 compliant websites, because screenreaders as they exist today suck.

Rich web applications (a la GMail, Google Maps, Flikr, Backpack, and other AJAX style applications) are a rennaissance of web programming. They are increasing usability at the expense of accessibility. The vast majority of users are sighted and on a PC. I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps.

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

[hacker]

"They are increasing usability at the expense of accessibility."

Unfortunately, accessiblility is going to win this one out, thanks to web services and RSS and many other things. Eye-candy is great, but without a viable fallback, it will die off. That is the nature of evolution, and this will go the same route.

"The vast majority of users are sighted and on a PC. I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps."

How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind. One of my colleagues uses 25+ point fonts because he can't see anything smaller than that, and he reads 8" from the screen.

The advent of the Internet is enabling people with disabilities to meet and join other communities of disabled people (visually, aurally and otherwise), and those communities are strong and growing. Elderly people are getting on the Internet, and many of them can't legally drive because of their sight.

While your own personal userbase might be fully-sighted, don't assume that your demographic expands to the rest of the world... it doesn't.

If the most-important part of your website is the presentation and not the content, you're doing something wrong. Yes, presentation makes the content look better (in some cases), but the users who are there won't be buying your product because you have pretty fonts or a spiffy intro in Flash. They'll be buying it because of what it DOES for them.

Re:Not really new, but interesting

[Pete]

Internal web application development is a bit different. For example, I've been working on a web application which (at the moment) only works on browsers using the Gecko renderer and Spidermonkey javascript engine. It should work on Safari/Konq and Opera, but they're still coming up short in a few places.

But it flat out doesn't work at all in IE. Doesn't even come close. Does this matter? No, not at all. Because the people I'm developing this for don't care what browser they're using. As far as they're concerned, they double-click on the Firefox icon to run this application, and that's all that matters.

It's kind of weird when you start thinking of webapp development in these terms, but you quickly get used to it. Intranet webapps are different (often very different) to internet websites.

Re:Not really new, but interesting

[JimDabell]

Classes are for CSS behavior, not JavaScript behavior.

I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.

The class attribute is for grouping disparate elements. This is very useful in both CSS and Javascript, but it is not "for" either. It's a general mechanism - you can use it in custom written shell scripts that work with wget if you like, no Javascript, no CSS, still perfectly fine.

If you are confused about what an element type or attribute is for, consult the specification. It is quite clear in stating that it's for "general purpose processing by user-agents".

Re:Not really new, but interesting

[Hamhock]

Then you're asking your company to be put out of business.

Hmmm. Is Google going to be put out of business if their maps application doesn't work on every (any?) cell phone or PDA? I think not. If your content is the app itself, and that app only works with JavaScript and CSS, then so be it. You're not doing anything wrong by requiring that of your users.

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

[Shaper_pmp]

You've got a lot more flexibility in intranet development, but you're still voluntarily walking into vendor lock-in, even (as with Firefox) if the vendor vends for £0.

Stick to the standards, and all will be well. Even proprietary extensions from open-source apps aren't always perfectly safe - how would you feel if you'd invested in loads of Mozilla Suite-specific code, when Firefox came out? Or how about if (god forbid) Firefox dies on its arse, and the only options are Opera or (hackcoughspit) IE? You're voluntarily and short-sightedly stuffing yourself, for no real gain.

I really don't understand why people have a problem with sticking to standards. You can basically do anything you'll ever want or need to while still having validating code, but people persist in treating it like some kind of groupthink. Does anyone argue that C/C++ code doesn't have to compile? Or how about the ISO standards for C/C++ - pointless? Or are they the reason we still basically have one language each of C and C++, instead of hundreds of incompatible, balkanised rip-offs?

Re:Not really new, but interesting

[DavidTC]

And instead of spending the time making it work with standards and standards-compliant browsers...

Where, exactly, did he say anything about violating any standards? He said it didn't work on IE, which probably means it is using standards correctly, specifically CSS2.

Re:Not really new, but interesting

[FLEB]

dont be so hasty to dismiss great tools because people can't use them right. a nice site made entirely in flash can pleasant to use. dont focus on the bad ones. . .

Well, for one, "Click to download the plugin" on a blank screen really isn't the pinnacle of usability. Flash isn't a "standard", it's a plugin. Granted, it's a very popular plugin, but it isn't a universal expectation.

I'm a fan of incidental or mixed Flash, but there still should be some way to get the meat, the information, of the site in plain HTML, especially with something as mass-market as a realtor's site.

That said, I've found very few cases where I can't execute a given layout that works cross-browser (with the exceptions of IE/Mac and NS4.0-, which fail to render most anything correctly). It might take some planning and forethought, but that's what makes one a web developer, as opposed to a Flash developer, or any other goob with a keyboard.

Re:Not really new, but interesting

[Pete]

Well, I am actually coding it to be standards-compliant. And it is. It just doesn't YET work correctly in KHTML/KJS or Opera (believe it or not, neither of those engines are perfect - of course, neither is Gecko/Spidermonkey, but G/S is less imperfect :-)). But they're getting closer - it seems that every time I test a new Konq or Opera release, more things work correctly.

This is not your usual web application. It's all a single page, and almost every user action is handled with asynchronous XMLHttpRequests. It's pushing the envelope a fair bit, yes - but my boss is happy and so I'm happy too :). It is pretty amazing what you can do with Ajax when you don't have to be held back by IE limitations.

What if your employer opens the site up to a new partner, which only uses MSIE? What now?

Well, it's pretty damn simple. If they want to use the app, they use a supported environment *shrug*. Just like any other software vendor. Except it's about a billion times easier to install and run an alternative browser than it is to install and use an alternative operating system on your computer (when my boss was demonstrating to a potential client, it took him all of two minutes to (a) download, install and run Firefox and (b) get our app running on the newly-installed Firefox).

In some ways it's easier if you think of it like the web application is a "real" application. It's just that you install Firefox (or Mozilla, or K-Meleon) on your desktop to "run" the application (instead of, eg. a Java or .NET runtime environment). And of course in the near future our app will work with every major browser except IE.

Re:Not really new, but interesting

[mcfuddlerucker]

>> the guy who wrote it is either lazy, unprofessional, working to an unrealistic schedule or shit at his job.

Thankfully you put that middle one in there. I was about to cloud up and rain all over your ass.

Many of us want to do, and vocalize the importance of doing the right thing, but our hands are tied. Don't forget that.

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

[MarkEst1973]

"How do you know the vast majority of users are sighted on a PC? There are literally thousands upon thousands of users who are using a PC, who are legally blind or entirely blind. One of my colleagues uses 25+ point fonts because he can't see anything smaller than that, and he reads 8" from the screen."

Yes, there are many thousands, tens of thousands even, of blind, partially blind, and color blind web surfers. There are hundreds of millions of sigted users. Blind people are a minority group.

Section 508 to the rescue!

We cannot discrimate against people, says the US Gov't, so they mandate all gov't sites and applications be Section 508 compliant. I know more about color pallettes than you do, because a color blind person will not be able to read all the text. Blind people can't read it at all.

I've used JAWS. It sucks. It's awful. It's the worst browsing experience I've had in my life. And it could be made so much better for a blind person if JAWS had a DHTML capable browser built in.

Instead of "skip nav" like I mentioned above, why not present a non-visual menu for the screenreader? "Press 1 for My Profile" and DHTML renders that section (via innerHTML, CSS, etc.) dynamically. We could easily shuffle the user to that new DIV complete with its own non-visual submenu (Press 2 for Password, Press 3 for Listserv, etc).

But now? Blind users have to guess what is primary navigation and what is secondary. There is no easy way to group them to make it obvious that a section of links is secondary navigation.

DHTML, Javascript, and CSS built into JAWS could make for a much more accessible solution than we have today.

Re:Not really new, but interesting

[Anonymous Coward]

I agree with this parent.
I own a company that employs graphic artsists with web experience to design our pages and web developers who hack up their pretty little designs and make them work. If your design cannot gracefully degrade with less capable browsers, then you've failed your job as a developer. You would have gotten better results by using PHP to dynamically generate a jpeg image for your readers to view.

Anybody who preaches 100% standards compliance hasn't actually written a real world website. Likewise, someone who doesn't attempt to use standards where they can is similarly naieve.

I can't count the number of times I've had to do browser detection to make sure a specific "gee-whiz" feature works for both major browsers (Gecko & MSIE 5+). That being said, those Gee-Whiz features degrade gracefully with less than optimal browsers. When you're coding a dynamic language like PHP or ASP, it's nothing to present in lightly formated plain text when you detect your readers are using NS 2.0.

I have to laugh every time I see a splash page on a site that just has some fancy flash animation in it's code. If you're going to put an obnoxious splash page on your website, at least have it do something usefull like preload images and do browser and resolution detection so your visitors recieve the optimal presentation based on their capabilities. Go ahead and open your page on a Blackberry, if you can't get to the product your selling (and every website sells *something*) then you've failed. Yahoo.com degrades very well even down to text only cell-phones.

I'm working with a company now that is busting their asses to ensure their intranet is Gecko compatible because they've decided to push firefox as their corporate web browser (for security concerns)

If you're designing a website with the look of the site more important than the practicality of the site and your site is only viewable from MSIE6 with Macromedia Flash installed, then you're not a web developer, you're a graphic artist who's obviously out of their element.

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

[Pete]

*sigh* Look, I'm not going to make fun of you - it'd be too easy :). Just go have a quick game of Weboggle, hopefully that will clarify your understanding of the kind of applications (yes, real live applications) that can be built with Javascript and run inside a web browser.

Asynchronous XMLHttpRequest has really opened a lot of doors for this sort of stuff, and there's still a great deal of scope for new and interesting web applications.

Re:Not really new, but interesting

[leoboiko]

Which is why I like to serve XHTML 1.1, and use a xslt script (good for Sablotron, btw) to generate fallback .html versions. Tie with Apache content negotiation and that bad browser will get his plain HTML 4.01 files, while browsers which are cool will ask for nice, valid application/xhtml+xml XHTML 1.1.

XHTML 1.0 is bogus. If you're going to serve text/html tag soup, you might as well serve plain HTML.

Re:Not really new, but interesting

[russx2]

When I turn off Javascript, the page stops working properly.

On what browser/platform?

I highly doubt this is the case because, as the author explains, all 'magic' extras are written AFTER the normal elements have loaded. So without javascript, nothing changes.

What I suspect you have done is disabled Javascript in your browser and then tried to use it - without refreshing the page. I've just tried in this in Firefox and it seems to be the case. I don't think the chances of someone disabling Javascript mid-way through using the page are worth worrying about ;-)

Please correct me if I'm wrong though.

Re:Not really new, but interesting

[AKAImBatman]

Completely and utterly wrong.

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Elements are nodes in the document tree.

Exactly what I said. Thank you for agreeing with me, Mr. Troll.

And the HTML specification actually says "elements are not tags"

Precisely. Tags are represented by a sub-set of elements. Thus in certain cases, the two words can be used interchangably. Cases like, I don't know, the one I was using originally?

But wait! We have to keep on trolling!

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there.

That whooshing sound is you trolling right on by. Think, Mr. Troll. The element is created dynamically. Just WHO do you think would have a handler on it?

The correct appropach is to use attachEvent and addEventListener.

Except that attachEvent is an IE quirk, and addEventListener is not supported by IE despite the DOM 2 Event Standard having existed for quite a long while now.

But wait! You're TROLLING! Why bother with little details like alternate implementations?

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Compatibility with non-CSS user-agents is a design principle of CSS.

Backward compatibility is a design principle, not the primary purpose. CSS enhances the document presentation so that the document can render in alternate environments. This is in direct opposition to the HTML concept, which was designed only for screen usage. For example, you're ignoring this entire section from your link:

Accessibility. Several CSS features will make the Web more accessible to users with disabilities:

* Properties to control font appearance allow authors to eliminate inaccessible bit-mapped text images.
* Positioning properties allow authors to eliminate mark-up tricks (e.g., invisible images) to force layout.
* The semantics of !important rules mean that users with particular presentation requirements can override the author's style sheets.
* The 'inherit' value for all properties improves cascading generality and allows for easier and more consistent style tuning.
* Improved media support, including media groups and the braille, embossed, and tty media types, will allow users and authors to tailor pages to those devices.

Not to mention the section on device independence!

Vendor, platform, and device independence. Style sheets enable documents to remain vendor, platform, and device independent. Style sheets themselves are also vendor and platform independent, but CSS 2.1 allows you to target a style sheet for a group of devices (e.g., printers).

But you go right on trolling, Mr. Troll. You seem to enjoy it SOOOOOOO much.

You've just blown a lot of hot air and called me names. Who's the real troll?

I've called you a troll. Which you are. Why? Because you initiated an uncalled for attack, ignored the complexities of the issues, picked at nits, carried a holier-than-thou arrogant attitude, made sure your post was content free, and now just tried to call me a troll. (To you folks back home, pay attention. Trolls will often accuse you of trolling in an attempt to remove the spotlight from themselves. Don't fall for this utterly stupid ruse!)

Enjoy your trolling day, Mr. Troll. Oh, and don't let the door hit you on the way out. :-)

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Re:Not really new, but interesting

[Shaper_pmp]

Yeah. I was going to perjoratively leave it at the other three, but then I remembered some of the piles of festering crap that have been uploaded to our web server in the past, while I knelt in the background crying and beating my head against the desk.

Seriously - what is it with managers who hire you to be "the expert" in something, then refuse to listen to your advice on scheduling?

Re:Not really new, but interesting

[Paradox]

Maybe it's because they're not really developers? They like to pretend they are, but they're not.

Some of the most talented developers I know work heavily with web applications. Are they any less programmers because you're suffering from reverse domain envy?

Writing javascript no more makes them developers than writing shell scripts would. And of course, HTML and CSS are *NOT* programming languages!

Would it shock you to know that, on the spectrum of languages, Javascript is actually much closer to Smalltalk, Ruby, Lisp and OCaml than Java is? Javascript is a fully Object Oriented language, complete with anonymous functions and a prototype-based class system that is extremely powerful?

And XHTML is just XML by another name. Get over yourself.

Would it hurt you if I told you that it's probably a better language design than C++ and Java? Imagine what a developer like you and I has to go through migrating a C++ project from GCC2.95 to GCC3. Now do that every day just to make things work.

Some of them may be graphic design weefles, but not all. Web engineers deserve respect, be they EJB Machines or Rails Honchos.

Real developers test their code. Web "developers" do not. At best they'll make sure their pages work with Internet Explorer and Firefox. As if those are the only two browsers in the world. Test on last years Firefox? Hah! Don't make me laugh!

I assume you mean the HTML, CSS and JavaScript? Because the backends are usually tested very well. Java stacks and Rails have great unit test support.

It's unfair to compare the two. How exactly do you test a page layout? It's easy when I work on C++. I unit test things that have easily controllable inputs, easily recognizable outputs, and work in only one environment.

How the hell are you supposed to automate testing of HTML layouts? What heuristic makes a 1px border okay in some places, but not others? And if you can't automate the testing, then it costs A Lot of Money. When I do web consulting, I ask the customer what They Want To Pay for, and adhere to that.

The people working on the back end database and CGI interfaces might be developers, but those who write the HTML/CSS are not. Yes, there are some exception, but that only validates the rule.

Who can afford to have a separate web designer anymore?

But thanks for making arbitrary decisions on who and who is not a programmer. I'm sure loads of people appreciate it. Like the people who worked in Python in the 90s who weren't "real" programmers because they worked in a "scripting language."

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.

Re:Not really new, but interesting

[jonzawada]

A) It would be nice if one day developers would realise that communication is not always words. B) You can't tell people what to want or like and how they should like it. C) A developer building a website is often just as inappropriate as a graphic designer building one. There is a whole world of graphic design concepts, branding concepts and advertising ideals out there which have existed for decades before the internet and they are defended with just as much zealousness but unfortunately they are totally ignored and construed as insignificant or unimportant by the online development community, who often see communication as a stark, soulless and mechanical activity.

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)"

Re:Not the first time, but nice idea

[bedroll]

I had to create an app for making internal surveys for the company. The initial survey was a survey of the IT Department's performance. After finishing the app and having done the survey myself some 200 times I decided that it was very bland looking and needed something to spice up the design.

I was using radio buttons for a 1 to 5 rating. So I decided that instead of just boring radio buttons I would use smiley faces with an increasing amount of happiness. I took the smilies from MSN Messenger (our official and only allowed IM, which sucks as much as it sounds). The radio for 1 gets replaced by a crying face, 2 with a frowning face, 3 looks a little confused, 4 is smiling, and 5 has a big grin.

The result was just enough pizzazz to make the form visually appealing as you filled it out. Oddly, I didn't stop to think of it at the time, being in a homogeneous environment, my solution is just as friendly to non-scripting browsers. I use a regular radio button and use the onlick event to put the image over top, a non-scripting browser just wouldn't overlay the image. The only side effect that I hadn't forseen: One employee put in the comments section that she loved the smilies so much she put one of each rating just to see them. She gave us inaccurate ratings (including bad ones) just to see the smilies, and didn't change them before submitting.

The real question is

[Rosco P. Coltrane]

Will Lynx render them correctly with ascii-art?

Re:The real question is

[AKAImBatman]

Will Lynx render them correctly with ascii-art?

Yes, actually. While I'm none to keen on the idea of supporting old browsers in DHTML/AJAX/Whatever-you-want-to-call-it-this-week applications, his solution is designed to allow for normal checkboxes to show in browsers that lack JavaScript. As a result, the normal "text" checkboxes would show in Lynx. At least until Lynx gets full JavaScript and DOM support. Then you have problems. ;-)

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.

Click here

[FunWithHeadlines]

[ ] This is a good idea
[ ] This is a kludge
[ ] I didn't read TFA, but I like clicking boxes anyway

Re:Click here

[hcdejong]

Of course they do. Here's a screenshot of the form after I entered my choice:

[ ] This is a good idea
[ ] This is a kludge
[x] I didn't read TFA, but I like clicking boxes anyway

Re:Click here

[Anonymous Custard]

worked for me too...

[ ] This is a good idea
[ ] This is a kludge
[ ] I didn't read TFA, but I like clicking boxes anyway
[X] CowboyNeal

Is this a good thing?

[AtariAmarok]

Is it a good thing to have controls that deviate from the standard so much that they aren't even recognizable anyore, like the green/grey round toggle button that replaces the checkbox on the sample page? Why disguise standard controls so the user will have to spend some time trying to find out what the standard controls are "hidden as"?

Re:Is this a good thing?

[op12]

Ideally, the context of your page would make the function obvious. The ability to change it to fit any page style is the major benefit. Sure it's nice to see the standard checkbox, but if it completely messes up an otherwise "clean" or different looking interface why not change it?

Re:Is this a good thing?

[twocents]

For most Web pages, I think this is not a very good idea. From a design perspective, I can respect the desire to have control over elements on the page, but different interactive elements create more confusion than anything. There are very few things I hate more than having to figure out how to access parts of a DVD or Web page; it might look neat the first time, but I'm interacting with said interface for content, not just to interact with the interface.

Re:Is this a good thing?

[ubernostrum]

Is it a good thing to have controls that deviate from the standard so much that they aren't even recognizable anyore, like the green/grey round toggle button that replaces the checkbox on the sample page? Why disguise standard controls so the user will have to spend some time trying to find out what the standard controls are "hidden as"?

In some cases, yes. For example if you're running a review system you could use stars (as in one of the examples on that site) and users would reasonably understand how it works. In fact, since using stars for reviews is a convention older in our society than the Web, this might improve usability.

Damn you, Slashdot.

[bigtallmofo]

I just hope the marketing people that work in my company aren't reading Slashdot today.

Otherwise, I'll be making fancy checkboxes for the next 2 months.

Damn you, Slashdot.

Are you joking?

[dave420]

This is what passes for a story on slashdot these days? This isn't new. People have been re-creating radio and check boxes using DHTML for YEARS. Shit, I remember first doing it 2 years ago, and I didn't think it was anything special when I did it.

Do editors not read articles any more? shit.

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.

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.

Accessible?

[Anonymous Coward]

Not to be an accessibility Nazi, but you can't tab through the form elements.

I would prefer to have normally and familiar elements that i can tab through than fancy graphics that don't work as expected.

Re:Accessible?

[senocular]

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

Re:And, of course

[Rosco P. Coltrane]

Hey, here's a question-- Why do we [i]need[/i] styled checkboxes? I hear those words and I just get this mental image of style kicking contents in the nads over and over and over.

Not to mention - but it seems nobody really cares about this, and apparently bringing the subject up always generates a deluge of "we won't hold browser technologies back because of *this*" answers - web developers are so busy beautifying web pages and turning everything graphical and snazzy that you can always count on one category of people getting screwed with this trend: blind people.

They are the truly forgotten of this embelishment, and java[script]tization of the net. I wish web developers cared more about (1) complying strictly with W3C recommendations for accessibility and (2) not forgoing accessibility just for beauty...

Patent It!

[ryanjm]

The author should apply for a patent for this. I'm sure it'd be approved.

On bells and whistles

[PIPBoy3000]

There are certainly some people out there who are impressed by cool graphic tricks.

After writing web applications for ten years, though, I find that more and more people simply want to get the job done. Perhaps it's that I work in Healthcare and my customers are busy people caring for patients.

The other thing that makes me nervous about bells and whistles is that they add complexity to things. Complicated things break. Browser makers have changed how they implement CSS and DHTML before and there's a good chance they'll change it in the future. Basic support for checkboxes will last another fifty years.

Horrible and confusing

[baadger]

They look horrible and confusing to me, especially in the example the author has given. If i had come across that form on a page and it said "please select a rating" or the like I would be momentarily confused.

I think there is a good reason why radio buttons and check boxes haven't been styled too much - it's because they are perfect the way they are.

If you want to style a checkbox or radio button atleast make it look like one, get some inspiration from the likes of Opera skins.

Re:Horrible and confusing

[DevanJedi]

Just because the particluar examples are bad doesn't mean the entire concept is bunk. If correctly labelled and used when appropriate, this would make things much more aesthetically appealing. They don't have to look like Radio buttons in order to offer the same functionality. Netflix users are familiar with the star-ratings- if the usage is as intuitive as that, people will do it without second thought.

Javascript != Solution

[Oz0ne]

I am very glad it degrades well, but javascript is never a solution. The goal of any web developer worth his salt is to make something universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.

It's a nice hack admittedly. Heck I may even use it on personal sites.

Re:Javascript != Solution

[C. E. Sum]

The goal of any web developer worth his salt is to make something universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.

Funny, I always thought the goal of a (web) developer is to develop a project based on the requirements at hand. As a rule of thumb, the goals you state are good ideas. But saying the JS is never a solution is .. well .. stupid.

Would you also say that the goal of any Windows developer is to have their applications run on Windows 3.1? Requiring the client to use JS (or Flash or whatever) may be a bad idea, but never is a long time. There is a time and a place for even these technologies.

It seems expecially benign when (as in this case) the goal is to enhance the experience of users who happen to be running it, rather than requiring them to have it to access the site.

Heck, even The WASP has a JS include at the top of their landing page!

Missing the point

[illtron]

A lot of people seem to be missing the bigger point here. It's not that he's replacing checkboxes with images, it's that he's managing to do it while keeping the page properly structured and accessible to all browsers. While the page isn't quite all the best HTML underneath (what's with the tables?), if you look at the forms, it's proper HTML and not some javascript hack that will break old browsers.

I think that's the point, anyway.

Accessible??

[dFaust]

I tried these in both Opera 8 and IE 6 and couldn't activate/de-activate any of the controls with the keyboard. Am I the only one having this problem??

Accessibility my arse.

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.

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.

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:Why JavaScript?

[Rosco P. Coltrane]

Javascript is dangerous, not standardized, and crap.

Javascript isn't necessarily crap if used correctly. However, the only times I get to "experience" it are when websites want to do something stupidly useless, like resizing windows or goofing with the mouse pointer, or bury me in multiple cascading popups.

So, I don't know if it's really dangerous or not standardized, but it's definitely annoying and therefore I turned it off, and I don't go to sites that insist on using it.

Find another alternative please.

Flash? same problem, it's annoying (and CPU-intensive).

doesn't work for me

[real_smiff]

Tab works, but Space does nothing (or in Firefox (Deer Park Alpha 1), it scrolls the page down as normal). IE6 has the same problem plus the icons flicker horribly when moused over. maybe i'm missing something?

Keyboard functionality is missing

[mdbelt]

This looks nice but, as many seem to forget about, the keyboard functionaility (eg: Tab then Spacebar to select) just isn't there. I have several users that still don't feel comfortable with a mouse.

Slow News Day

[adinu79]

Definetely a slow news day on Slashdot today. What will they report next? Seeing the back of your head finally possible thanks to an ingenious mirror system. Sheeesh.

Not a solution

[Zebra_X]

Yes using images as form elements can work. Integrating them server side is difficult.

Though my real beef: every mouse over causes a *flicker* of the image.

End users don't like "wierd" behavior in user interfaces. There is no reason that the image should disappear and re-appear when the mouse goes over the image. This behavior gets worse as the connection speed of the user decreases.

This sort of behavior makes people who are not fully comfortable with the computer uncomfortable reducing their desire to interact with an application that behaves in this manner.

The flicker bahavior has also become rampant in drop down menu and site navigation everywhere. Back in the day we used to cache images but now we just accept sub-standard UI behavior because caching images "is a pain".

My 2 cents

gmail...

[Fusen]

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

Re:Why JavaScript?

[mrchaotica]

However, the only times I get to "experience" it are when websites want to do something stupidly useless, like resizing windows or goofing with the mouse pointer, or bury me in multiple cascading popups.

The corollary of that is that when JavaScript is used correctly, you don't notice it (e.g. Google's various pages).

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:And, of course

[srmalloy]

Heh. I wonder how many people are confused when they use UBB code on /.?

It makes it easier for the people writing the forum software to be able to parse out HTML tags and force the use of tags in a different format in order to control what posters can do in their posts; they can strip out all HTML tags, rather than making the parser smart enough to be able to identify malicious or subcompetent HTML coding. Of course, you then wind up with making people switch between thinking in HTML tags and thinking in your tag format. But if the rest of your functionality is good enough, people will use it -- and the ones who are good enough to be writing HTML directly into a text editor should be good enough to make the mental switch.

And, of course, if you don't bother to preview your post and actually look at it to make sure it looks like you think it should, then you deserve to look silly if you screwed something up.

Fucking graphic design majors

[Thaelon]

One of the most fundamental concepts of good UI/GUI design is that you DON'T INTRODUCE NEW THINGS.

Everytime you introduce something new the user has to learn how to use it or what the fuck it is. This is bad. Really bad. You just won't believe how vastly, staggeringly, jaw-droppingly bad it is.

It may seem incredibly anal, stale and anti-progressive but that's the whole point. There's no such thing as an innovative interface because innovation has connotations of something both new and better. In the realm of Human Computer Interaction (HCI) new and better are mutually exclusive. Good UIs are simple, intuitive and introduce absolutely nothing new. Ever.

There are only two truly intuitive interfaces in existance. The nipple and the vagina. The rest you have to learn how to use.

Save the styled checkboxes and radio buttons for other people in your yuppie coffee house. Your average user doesn't want them, won't understand them, won't appreciate them and doesn't care what they look like.

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.

Re:Fucking graphic design majors

[Xepherys2]

Wow, I'm sorry, Windows 3.1 was newer AND better than DOS. Windows 95 was CERTAINLY newer and better than Windows 3.1. Holy crap, Windows 2000 was even BETTER STILL! What? Windows XP? OMFGWOWOWOWOMFG!

But seriously, how can you really believe this? it's not "anal, stale and anti-progressive", it's... well... ignorant. I'm not trying to troll, and to put that foot forward, I'll explain myself.

Interfaces are constantly changing. They have to. If the interface does not change, it means there are no new features. If there are no new features, it means that we are not getting something out of a product that we could. If you remember the "bag phone" from the 90's. The "portable" cellular phone in a bag for your vehicle. It was big, heavy, bulky and could call people and that's about it. Do you have a cellular phone now? Do you use text messaging? Do you use the web on it? I don't know, maybe you don't, but a LOT of people do!

What OS do you use? VAX? HP/UX? I'm sure you use something with a modern interface since you seem to like "simple GUIs" and those OSes are CLI. So then, what version do you use? Something old? MacOS 6.x? Windows 3.0/3.1?

There are infinite innovative interfaces. Also, humans THRIVE on learning new things. While many people are technophobes and/or have difficulty learning new things, learning and adapting keeps your brain strong. Innovation fuels innovation. Without it, the human intelligence average would slowly decline. Is that what you want? More ignorant people (more as a quantity AND a quality)?

*sigh*

For Pete's Sakes!

[Tablizer]

We still don't have semi-standard editable grid and collapsable tree/outline widgets, and you guys are fussing about pretty borders around checkboxes? Pardon me for my outburst, but you are a bunch of fucken girlie men!

Let's resolve the practical issues first, and THEN focus on pretty frilly borders.

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?