Regarding the checkbox & radio-button borders that still appear in many browsers

I vote for adding customizable classes to the checkbox and radio elements whether or not we then use those classes to fix the currently styled input borders, or remove the border styling altogether (and let all input types revert to their browser defaults)

My reason is simple: I'd like the freedom to customize those different input types built-in to the program, rather than having to change thirty different template files myself, and then be forced to do the same with each new upgrade

It would take three simple "search-and-replaces" to do this, and would add less than 2 KB total to the entire program, so in the short term, it's not a big deal Having said that, however

Back when this was first discussed, Justin was leaning towards leaving things as-is because:

[extra classes will] never ever get applied to every single thing - the buttons are bad enough, but it makes you have to stop and think

and I can now better understand and empathize with this, having since hand-coded a fair share of redundant name and id attributes into the program's tags Sure, typing:

isn't nearly as bothersome as typing:

But it is still an annoyance, and since Justin's the one who'd be dealing with that extra little annoyance more often than anyone else, I say it's ultimately his call

And FWIW, yes, I also have a preference for the border styling question, if we're vote-counting:

Given the three options at the bottom of: http://mojo skazat com/cgi-bin/dada/mail cgi/archive/dadadev/20050903121510/ , I'd prefer that borders either stay as they are or, if those redundant classes are put in, that they stay with the current styling but be made cross-browser compatible

• The fixable radio/checkbox bug notwithstanding, it gives a clean, professional, and contemporary look to the program

• The default "inset 3D" text field styling in the most common browsers out there, IE and Moz/Firefox, look clunky and old Seeing that sort of thing can make it seem like little care and attention has been put into the design, and if anything, this can reduce my trust and confidence in the program I'm using (This is a little like seeing to many speling erorrs: my subconscious says, "sure, you may have programmed it well, but did you /look/ at it afterwards?")

• As for the argument that changing the appearance of form widgets is always bad usability: isn't that what everyone used to say about underlined blue hyperlinks? (In other words, there's dumbing things down, and then there's assuming everyone is stupid and for me, assuming an input field with a solid-bordered box [which everyone has seen offline hundreds of times] is in any way confusing crosses that line )

• And of course: with just two added classes, all the different input types can be targeted and customized separately:

input{}

would apply to text fields,

input checkbox, input radio {}

would override that for well, you know, and

input plain, input processing, input cautionary, input alertive {}

(which are already in the stylesheet) would override the first rule set for the buttons Nice to have that flexibility plus, the people who'd still prefer the browser defaults can easily get them by deleting all three rule sets above from the stylesheet, with minimal added weight left behind in the templates, so it's equally as customization-friendly for them, too!