Back when I was testing the new form inputs for some HTML5 slides I was making, Opera was the only browser who popped up a colour wheel (and it didn’t work with keyboard, and it made the page jump/showed the colour selector at the top of the page on Linux but not Windows), but other browsers who had validation would insist the colour type input was “wrong” if you didn’t type in a hex number. Bleh.
There’s only one form type I’ve ever used where I am selecting a colour. It’s e-commerce. Items are generally offered in a range of things: sizes, types, colours. When I first saw there was a input type=“color” I thought, oh okay, some way to add semantics or something to form inputs asking for colour, maybe to get around the issue where the same colour (say, “tan”) gets a bazillion other retarded names, especially with textiles (sand, various types of rocks, types of animals, types of dried grass… they do get creative with their names for a colour like “tan”). I dunno. But the input clearly isn’t made for that: the input allows users to visually select a colour from infinity, not from some limited, chosen set that a manufacturer has set.
So since you can choose theoretically any colour, the only thing I could think of was something like, an online Photoshop app thingie. Except, I would expect if someone made such a thing, they would build in that tool the way they would need to build in all the other tools.
So as an input it’s pretty confusing and after I made my slides, I forgot about it and never used it again. Some new things seem to have broad application. Other new things… no idea.
I took the idea that geoloc was once part of HTML5 spec from comments by standardista type peoples (they could be wrong but I have no way of knowing this) and when I had a copy of Bruce and Remy’s book (loaned it from a friend so don’t have it any more; out of date anyway now, thinking of getting the new one) they have a section on “It’s not HTML5 anymore but we’re covering GeoLoc because it’s new and cool and why not” and I thought it explained that the spec had been separated. But since I don’t have the book right in front of me now, I have a doubt.
And yeah, I’ve seen your spec proposal, but I didn’t think that was intorucing ARIA to HTML5… instead, as I was reading the history of HTML5, it seemed this happened:
-HTML was to stay dead, and XForms came out.
-Examples of XForms I saw from 2005 had these neat-o aaa:required and “wairole” attributes in them… the beginnings of ARIA
-When Mozilla, Opera and later Apple decided to continue working on HTML (not XHTML) forms, so before they went all out and said “let’s make HTML work with apps”, they incorporated the roles and attributes into the “new” forms.
-That finished, they thought “why stop here? W3C isn’t interested so let’s just do our thing, now for web apps, see where we end up” and HTML went further.
-Whenever this started becoming “HTML5”, ARIA was baked-in (though at a still-early, unfinished state as even now some things are still being created and edited), while “HTML” did not have it (though if FF back then supported it, you could just add it and suck up the validator b*tchings).
Correct me if I got something there wrong, because I wanted to give that history overview in the future sometime.
So when I was on the (w3c) HTML5 editor’s draft page that had the ARIA stuff and there was later a link to a separate section (regular WAI-ARIA stuff) it seemed like all HTML5 references to ARIA were now only the W3C WAI-ARIA page.
I’ve gone from CSS like
input[type=text] {
styles for everyone who’s not a submit, radio or check, or basically, all the “type-in boxes” excepting password;
}
Or more usually, I’d do
input {
styles;
}
and just over-do with input[type=submit] or whatever.
to now, if I’m going to use type selection,
input[type=text], input[type=email], input[type=url], input[type=tel]… {
select all the “type-in boxes”, plus I’ll add more for hover/focus etc…
}
(or other way, but listing other new types that aren’t boxes)
meaning either abandon using type for style selectors (which I ended up doing… adding classes kinda sucks and I thought “Here would be a great place for a regex! input[type=text|email|url|tel|number… etc]” but sadpanda) or just use them all. For Javascript, it’s a regex. I set a pattern with all the types I’m going to hit and then do a .match on them.
I figure if I do the list-every-type-of-input-comma-separated, not only could that be a lot of typing (not in my editor but anyways) but would probably be slowing down the parser (unless it goes left-to-right here? first finds inputs and then checks their types? That would be jawsome) more than when I hit all those inputs with a single type.
oooh! That would be nice! Also if autocomplete defaults off too. And autofocus! Is there a proposal for that?
Duh!! I completely forgot about those (and I think they were in Bruce and Remy’s book)! We were manually using Javascript to push the errors offscreen or place abso-po’d messages on top of them to cover up, to add Dutch ones and something useful for “pattern” in. Doh.