August 17, 2005 at 8:13 AM
It's got a bunch of unexpected behaviour which would need to be looked at before I'd use it: - Opening a dropdown can only be done with the dropdown arrow, not by clicking on "please select". - Closing a dropdown can't be done by clicking elsewhere in the document. - In Safari, you can't select radio buttons or checkboxes by clicking on the label, even though it shows a hand-cursor when mousing over them That said, it's a very nice start, or even, it's probably about what a v0.9 would be. On the other hand, I've always wondered what's wrong with the default form controls that people always try doing things like this...
In addition to the issues Marten pointed out, IE has a similar problem with the radio buttons (and checkboxes). You can only click the label to activate them and not the actual button/checkbox (even though hovering over the checkbox/radiobutton changes the cursor to a hand). This is the opposite of what Marten reported in Safari.
I do not understand the point of customizing forms like this. Forms are all about functionality, and this changes the behavior which I find extremely annoying. Also, custom forums are bound to break on some browser/operating system somewhere, and forms are one of the last things you want broken on a site. That said, customizing the look of a form element may have it's place (such as a drop-down menu in the header of the site, etc.), but for your everday form, please just stick with the normal & functional method, even if it is ugly in some browsers/operating systems.
Re: Ryan Bates "...but for your everday form, please just stick with the normal & functional method, even if it is ugly in some browsers/operating systems." Well, it's not all about looks. Part of this package, IMHO the worthy part, improves accesibility greatly. For example, being able to click the text next to a radio button rather than just the radio itself is really useful and makes the form easier to use. That said, I agree with Ryan's assessment of the style changes. We as web developers must remember that our users rely greatly on familiarity. If a dropdown doesn't look like their plain-jane dropdown, they might not use it in the same way. Worse, they might not use it at all.
As I've already said in my article, the script is currently at v.0.9, just as Marten said. I have a long way to go with it but just wanted to show everyone a beta version so I might catch wind of some bugs that escaped me. Accessibility is a major issue on my list and I will not dare to release this script in its final version unless I can be 100% sure it meets such requirements. Scalability is another issue and I plan to work on that too so the script can be a breeze to use and to modify. I was already aware of most of the bugs reported here and on the comments at my own website and some new ones showed up as well. It's a long way to go, but I'm pretty sure the end result will be worth it as I believe it will not only improve the way forms look but also their usability.
"Well, it's not all about looks. Part of this package, IMHO the worthy part, improves accesibility greatly. For example, being able to click the text next to a radio button rather than just the radio itself is really useful and makes the form easier to use." Ummmm. that's what label tags are for. Anyway, there are loads of keyboard accessibility issues with the combo boxes that have already been pointed out. And really - what's big win here?
Keyboard shortcuts don't work. I usually fill forms by using Tab, Space and arrows. with that repaired .. everything would be perfect. There's no big win here, but some good looking forms.
For a similar example check out my post from earlier this year on styling checkbox and radio button elements (tabbing works with this method). ARC - Adam's Custom Radio/Checkbox Customiser
Well, I think the forms look really great. I hope we can see such nice forms on many websites in the future. :)