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."
html as an "interface" still totally lacks some basic things... like, oh, I don't know... sliders...
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.
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.
Javascript + Nintendo DSi = DSiCade
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.
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.
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.
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?
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.
Slashdot: 24 hours behind every other site or your money back!
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.
Accessibility my arse.
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).
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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?
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
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.
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.
Lost at C:>. Found at C.
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
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.
I'll give you some more fuel to pour on that fire:
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.
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.
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.
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.
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.
http://www.foobar2000.org/
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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".
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
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!
-- Have you ever imagined a world with no hypothetical situations?
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.
Question everything
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.
Two Minus Three Equals Negative Fun -Troy McClure
a nice site made entirely in flash can pleasant to use.
Name one.
FYI: the browser knows my preferences (font size, for one). It has controls to perform the typical browsing tasks (history, back, print, etc) without having to look for the navigational instruments on a website.
Flash has its place, as a supplement, but a pure Flash site is a symptom of a society which favors looks over substance and will sacrifice efficiency for flashy effects.
I've worked with the web html/scripting/javascript/dhml for years now; i'm by no means a standards nazi, but I do recognize the need for them; and as time goes on I go more in that direction. However, in spite of this I still get seduced by these types JavaScript dhtml 'pretty' applications. Even after all these years of spending so much time working on this sort of thing and then having to abandon it because
a.) it doesn't work cross browser platform;
b.) it confuses users who are ultimately more interested in function and not form. In fact this type of application actually creates more function problems in the sense that it takes away features that users like with form (tabbing though them for instance).
the best measure for this type of thing is really does the javascript/dhtml widget add functionally or take it away? (this is especially true for form elements) - if it improves appearance all the better. This example degrades usability.
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?
Everything in moderation, including moderation itself
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.
If corporations are people, aren't stockholders guilty of slavery?
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.
Information wants to be free.
Entertainment wants to be paid.
You just want to be cheap.
>> 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.
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.
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.
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.
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.
Prescriptive grammar:linguistics
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.
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? 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:Not to mention the section on device independence!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.
Javascript + Nintendo DSi = DSiCade
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.
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.
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."
Slashdot. It's Not For Common Sense
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.
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.
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.
Table-ized A.I.