Quote Originally Posted by Stomme poes View Post
Color type is useless and horribly does not fall back well: the expected typed-in data is a hex value. Right, soccer mom's gonna know a hex value.
The user isn't supposed to type anything. The user is supposed to choose a color from a well (or whatever UI the browser thinks is best).

Quote Originally Posted by Stomme poes View Post
And it's apparently not meant for e-commerce, which was the first thought I had for it: choosing the colour. But doesn't work that way, seems to be made for online PhotoShop or something really specific and weird. Whatever.
What do you want to use it for, specifically?

Quote Originally Posted by Stomme poes View Post
Also CSSing and Javascripting the new input types makes things more code for parsers, yay: isntead of input[text] or input.type=text, you're now adding a bunch of things. So now it's either a class or a regex, and it wouldn't surprise me if this didn't slow a parser down somewhere.
I don't know what you're talking about here.

Quote Originally Posted by Stomme poes View Post
I don't use the form validation much because the default error messages are horrid and don't help users. Overriding with Javascript sounds like extra work that could be avoided by just not having validation in the HTML and just have server-generated error messages on submit and possible Javascript validation on the front to catch people before they submit. Opera's "hey use a title for the error message and it'll get added to the error box" is super retarded, and hurts users who see title tooltips and screen reader users who generally hear titles on inputs. Plus the language issue.
Firefox has an attribute to override the error message. If that's what you want, you should push to get it added to the spec. Other than that, I don't see how setCustomValidity is harder than custom javascript validation which you say you would use instead...?