Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Check Boxes and Radio Buttons Conquered by DHTML 522

Posted by CmdrTaco from the making-things-prettier dept.
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."
This discussion has been archived. No new comments can be posted.

Check Boxes and Radio Buttons Conquered by DHTML More

Check Boxes and Radio Buttons Conquered by DHTML

Comments Filter:

  • Not really new, but interesting (Score:5, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Wednesday July 13, 2005 @10:43AM (#13053365) Homepage Journal
    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 (Score:5, Informative)

      by hacker ( 14635 ) <hacker@gnu-designs.com> on Wednesday July 13, 2005 @10:48AM (#13053424)
      "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 (Score:5, Insightful)

        by thirteenVA ( 759860 ) on Wednesday July 13, 2005 @10:59AM (#13053543)
        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.

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

          And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application, as XHTML was designed for.

          If your XHTML isn't being sent as application/xhtml+xml, then it isn't XHTML, period. Yes, I'm a purist like that.

          See Sending XHTML as text/html Considered Harmful [hixie.ch] for more detail on this.

          • Re:Not really new, but interesting (Score:5, Informative)

            by pocopoco ( 624442 ) on Wednesday July 13, 2005 @01:02PM (#13054863)
            >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/ [w3.org] 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 (Score:4, Insightful)

              by leoboiko ( 462141 ) <leoboiko@gmail . c om> on Wednesday July 13, 2005 @03:27PM (#13056550) Homepage
              Which is why I like to serve XHTML 1.1, and use a xslt script [8x.com.br] (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.

            • 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 [w3.org] 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 synt

        • Re:Not really new, but interesting (Score:5, Informative)

          by Shaper_pmp ( 825142 ) on Wednesday July 13, 2005 @12:12PM (#13054294)
          "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 (Score:4, Insightful)

            by mcfuddlerucker ( 883634 ) on Wednesday July 13, 2005 @12:58PM (#13054815)

            >> 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.

            • 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 (Score:5, Informative)

          by poot_rootbeer ( 188613 ) on Wednesday July 13, 2005 @12:20PM (#13054371)
          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 (Score:5, Insightful)

        by gstoddart ( 321705 ) on Wednesday July 13, 2005 @11:08AM (#13053636) Homepage
        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 (Score:5, Insightful)

          by hacker ( 14635 ) <hacker@gnu-designs.com> on Wednesday July 13, 2005 @11:22AM (#13053756)
          "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 [iparklikeanidiot.com]? Towed.

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

      • Re:Not really new, but interesting (Score:5, Interesting)

        by MarkEst1973 ( 769601 ) on Wednesday July 13, 2005 @11:18AM (#13053718)
        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 (Score:4, Insightful)

          by hacker ( 14635 ) <hacker@gnu-designs.com> on Wednesday July 13, 2005 @11:28AM (#13053809)
          "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.

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

    • I don't really see what's new about this solution - isn't this what web-developers have been doing for years?

      I know that I and several other developers I know have made "standard" Javascript libraries to do just this. - It's not rocket science, and this solution even lacks the "SELECT" element, which can't be styled very much, and is a "heavyweight component"[1], which makes it a prime candidate for swapping with a DHTML component.

      [1] Meaning that it's "on top" of everything else

    • Re:Not really new, but interesting (Score:4, Insightful)

      by Psychic Burrito ( 611532 ) on Wednesday July 13, 2005 @10:49AM (#13053437)
      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.
    • Note that "obvious in hindsight", or even "easily improvable upon" isn't at all inconsistent with "new".

      (I have no idea whether or not it actually _is_ new.)

      • That's not hindsight. Web devlopers (and sysadmins masquerading as programmers working on the web) have been doing that for a while now. It's a pretty obvious idea, but he did wrap it all up into a nice, clean package. For that reason alone, he gets some props - "web developers" don't generally do nice things like making their code readable or making it flexible - probably because most of them don't have serious programming background.

        I've done similar things several times before, where you wrap the leg

    • 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?)

      No, you don't want to support those guys; people using cellphones, some public terminals, Lynx or have turned off javascript are to be avoided... letting them use your site is bad, esp. if they actually could end up giving you money by clicking ads or buying services/products.

      Remembe

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

      And, innerHTML is evil.

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

      • Re:Not really new, but interesting (Score:4, Insightful)

        by JimDabell ( 42870 ) on Wednesday July 13, 2005 @11:52AM (#13054087) Homepage

        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 [w3.org]. It is quite clear in stating that it's for "general purpose processing by user-agents".

    • No, the author hasn't invented any new kinds of code or web controls or anything else. The entire point is to use existing technologies (you know, the ones that people's browsers will support) to address something that has been an issue for some time.

      As far as I know, this IS new. I've certainly never seen checkboxes and radio buttons (non-Flash) styled like this before, and I try to keep up with that kind of thing.

      I'm not that well versed in ECMAScript or the DOM but are your suggestions accessible like
  • 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)"

  • The real question is (Score:5, Funny)

    by Rosco P. Coltrane ( 209368 ) on Wednesday July 13, 2005 @10:44AM (#13053375)
    Will Lynx render them correctly with ascii-art?

  • Check Boxes and Radio Buttons Respond: (Score:5, Funny)

    by Anonymous Coward on Wednesday July 13, 2005 @10:44AM (#13053376)
    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 (Score:3, Funny)

    by FunWithHeadlines ( 644929 ) on Wednesday July 13, 2005 @10:45AM (#13053391) Homepage
    [ ] This is a good idea
    [ ] This is a kludge
    [ ] I didn't read TFA, but I like clicking boxes anyway

  • Is this a good thing? (Score:5, Interesting)

    by AtariAmarok ( 451306 ) on Wednesday July 13, 2005 @10:47AM (#13053414)
    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"?

    • On bells and whistles (Score:5, Insightful)

      by PIPBoy3000 ( 619296 ) on Wednesday July 13, 2005 @10:53AM (#13053488)
      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.

    • Re:Is this a good thing? (Score:2, Insightful)

      by op12 ( 830015 )
      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?
      • "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?"

        Do you have an example of a page where the "Style" is such that usual controls would not be a good idea? Is there a possibility that the fancy page is really overdone if standard controls will be "out of place" in it, even if the colors are changed?

        • "overdone" is really more of an opinion. It is possible that a page that uses these fancy controls is overdone, just in the same way that a page that uses any fancy new web design can be said to be overdone. In university, I worked with a prof who wrote all of his web pages in plain text with the same grey background because anything else would have been too fancy for him. It's all a matter of opinion.

          While it does pay to give consideration to useability, I don't think you can automatically point to a
    • Cause they look prettier.
    • I think it is. If you downloaded the sample code and played with it you would have seen that the code just uses images to replace the controls. You can replace his with what ever you like. If you have some artistic abilities (I don't), you could come up with very nice looking checkboxes/radio controls to fit better with a sites design. Or you could just check Google Images [slashdot.org] for radios [google.com] and checkboxes [google.com]. However, I do think that if you make them look too non-standard it could lead to user confusion. Though
      • "However, I do think that if you make them look too non-standard it could lead to user confusion."

        The sample page actually does include round checkboxes which look more like option buttons than checkboxes. Yes, thanks to this breakthrough, we can make checkboxes that look like option buttons, and vice-versa!

    • Because making things look flashy is far more important than making them usable. Look at recent versions of Windows and any modern *NIX desktop environment for a few hundred examples.
    • 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.

    • 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

  • Damn you, Slashdot. (Score:5, Funny)

    by bigtallmofo ( 695287 ) on Wednesday July 13, 2005 @10:49AM (#13053436)
    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.
    • At least your marketing people know to use javascript and html - ours "need" to use flash because they have no idea how to make a site using anything else.
      • The number of marketroids I've met who actually know about Javascript is vanishingly small, like maybe two whole people. The rest of them simply break it down into its component parts to figure out what it means. Since the word is a combination of both "Java" and "script", it's obviously a set of pre-rehearsed lines that, when spoken, spur your marketroid intern to action so that he/she will bring you more coffee.

        If you think that's bad, let me tell you about the months I spent trying to explain to a m
  • 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.

    • This is what passes for a comment on slashdot these days? This isn't new. People have been re-creating flame and rant comments using CTRL-C/CTRL-V for YEARS. Shit, I remember first doing it 2 years ago, and I didn't think it was anything special when I did it.

  • Spiffy (Score:5, Interesting)

    by generic-man ( 33649 ) on Wednesday July 13, 2005 @10:50AM (#13053445) Homepage Journal
    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.
    • Just a minor complaint, I don't think the winamp thing is about slickness so much as space, and also themability. If you've tried to make a player with as small a footprint (which is important, because they want people having it open while they're using other programs) as winamp using native widgets, on any platform, you'll find it's impossible. And I've never seen anything as easily skinnable (there are web pages that will make a skin in one click given a picture) as winamp.

  • are they really blinky for anyone else? (Score:5, Informative)

    by pezpunk ( 205653 ) on Wednesday July 13, 2005 @10:50AM (#13053451) Homepage
    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? (Score:3, Interesting)

    by Anonymous Coward on Wednesday July 13, 2005 @10:51AM (#13053463)
    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? (Score:2, Informative)

      by senocular ( 519317 )
      Firefox (Win) seems to have no trouble tabbing through them.
    • Not to be a reading Nazi, but he says you can at the top of the page, and Firefox Just Works.

      I'd ask you what browser you're using, but you're a useless AC so you'll prolly never read this.

      J.

  • Patent It! (Score:3, Funny)

    by ryanjm ( 882598 ) on Wednesday July 13, 2005 @10:52AM (#13053469)
    The author should apply for a patent for this. I'm sure it'd be approved.

  • Horrible and confusing (Score:3, Interesting)

    by baadger ( 764884 ) on Wednesday July 13, 2005 @10:55AM (#13053499)
    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.
    • 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 (Score:2, Interesting)

    by Oz0ne ( 13272 )

    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.

    • 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

  • Missing the point (Score:5, Insightful)

    by illtron ( 722358 ) on Wednesday July 13, 2005 @10:56AM (#13053519) Homepage Journal
    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.
  • Is it so hard to have those css and javascript scripts in the same html file so it's easy to just use "view source" as opposed to scrambling around to three different files?

  • Accessible?? (Score:4, Insightful)

    by dFaust ( 546790 ) on Wednesday July 13, 2005 @10:59AM (#13053544)
    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?? (Score:3, Informative)

      by AttilaSz ( 707951 )
      My results:

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

      Sheesh...

    • Re:Accessible?? (Score:2, Informative)

      by 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?? (Score:3, Informative)

      by Sentry21 ( 8183 )
      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? (Score:3, Informative)

    by matth ( 22742 ) on Wednesday July 13, 2005 @10:59AM (#13053547) Homepage
    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.

  • doesn't work for me (Score:3, Insightful)

    by real_smiff ( 611054 ) on Wednesday July 13, 2005 @11:02AM (#13053576)
    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 (Score:3, Insightful)

    by mdbelt ( 704599 ) on Wednesday July 13, 2005 @11:03AM (#13053584)
    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.

  • After a couple of decades experience with developing windowing widget toolkits on multiple platforms, would it be possible for the W3C to come out with specifications for widgets, themes, etc. using SVG?

  • Slow News Day (Score:2, Funny)

    by adinu79 ( 860333 )
    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.
    • "What will they report next? Seeing the back of your head finally possible thanks to an ingenious mirror system. Sheeesh."

      It's about time! Once my son wrote "Insert Brain Here" on the back of my bald head. I was laying on the floor, spinning around for hours trying to read it before someone finally told me what it said.

  • Now I can make my circle checkboxes and my square radio buttons!
  • In Konquerer tabbing between the checkboxes works... but when you press space to check/uncheck them it tries to scroll down the page instead of checking the item....

    That said... I'm sure it's a browser problem. This is some interesting work... and I just might put it to use.

    Friedmud

  • Not a solution (Score:3, Insightful)

    by Zebra_X ( 13249 ) on Wednesday July 13, 2005 @11:20AM (#13053741)
    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
  • Netflix's UI had that for ages. Yawwwwnnn.
  • Not to offend the guy, I mean it's nice to make something like this as a tutorial, but this technique has been implemented for many years. Saying that the lack of CSS coverage for radios and checks has been "conquered" by the Javascript image-swap is rather stretching it.
  • Just tried it with Opera 8 on Linux - all the images get doubled up, and the bottom-most group of "radio buttons" only displays one (doubled) item instead of all 5. Guess it still needs some fine tuning.

  • gmail... (Score:3, Informative)

    by Fusen ( 841730 ) on Wednesday July 13, 2005 @11:31AM (#13053840)
    isn't this the same as what gmail uses, and that's been out for quite awhile now.

  • Fucking graphic design majors (Score:4, Insightful)

    by Thaelon ( 250687 ) on Wednesday July 13, 2005 @12:09PM (#13054263)
    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 (Score:5, Insightful)

      by RosenSama ( 836736 ) on Wednesday July 13, 2005 @01:45PM (#13055346)
      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.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close