Moved over to HTML5

[zcorpan]

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

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?

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.

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

[zcorpan]

http://isgeolocationpartofhtml5.com/

Like ARIA, it started as part of the HTML5 specs way back when.

Neither ARIA nor geolocation was ever part of the HTML spec. (HTML5 now has a section on ARIA which augments the ARIA spec, though.)

[zcorpan]

Oh right, I guess they are removing the JS API's because it confused people.

Nope.

[Stomme poes]

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

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.

What do you want to use it for, specifically?

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.

Neither ARIA nor geolocation was ever part of the HTML spec. (HTML5 now has a section on ARIA which augments the ARIA spec, though.)

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 don't know what you're talking about here. (input types)

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.

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.

oooh! That would be nice! Also if autocomplete defaults off too. And autofocus! Is there a proposal for that?

Other than that, I don't see how setCustomValidity is harder than custom javascript validation which you say you would use instead...?

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.

[markbrown4]

Neither ARIA nor geolocation was ever part of the HTML spec. (HTML5 now has a section on ARIA which augments the ARIA spec, though.)

I guess I figured it was from the many online resources that do put it in with HTML5.

http://diveintohtml5.info/geolocation.html
html5please.com#geolocation

It doesn't make any practical difference to me if it's included in the spec or not.

[zcorpan]

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.

We have an open bug about fixing keyboard access with the color picker. Is the jump thing still reproducible?

That other browsers hadn't implemented the color picker yet doesn't seem to be a problem with the spec.

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.

You can actually suggest a list of colors with <datalist>, but you can't restrict which colors the user can pick, short of making the control invalid if the user picks a color you didn't suggest. If you could elaborate a bit on the e-commerse use case (something concrete like "user wants to buy a T-shirt that is available in three colors" or whatever) I could maybe file a spec bug asking for supporting a <select>-like color picker.

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.

I don't recall exactly what use cases led to the addition of type=color, but I don't think it was restricted to painting apps.

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.

Robert is wrong. I haven't read Bruce and Remy's book, though I'd expect Bruce to know the history.

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.

I think ARIA was unrelated to XForms and WF2. ARIA did at first indeed have namespaced attributes (because that was believed to be the "right way" at the time), and was implemented as such in Firefox. But the ARIA people wanted it to work in text/html as well, so we worked together to move away from namespaced attributes to no-namespace attributes which would work the same in text/html and XML, and that's what we have today.

The section on ARIA in the HTML spec was added much later, and is there to put restrictions on how authors are allowed to use ARIA in HTML, and to give default roles of HTML elements (so that e.g. <button> has role=button implied). The ARIA spec allows host languages to do this.

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.

Ah, OK. I see what you mean. It's more typing, but you don't need to worry about performance here, I'm pretty sure.

In most cases you could use input:read-write { ... }. It matches text, url, email, password, the date/time controls, and number, if it isn't readonly or disabled. Do you want to select readonly/disabled fields as well?
http://www.whatwg.org/specs/web-apps...tor-read-write

oooh! That would be nice! Also if autocomplete defaults off too. And autofocus! Is there a proposal for that?

For autocomplete, see http://www.schemehostport.com/2011/1...ituencies.html

For autofocus, the spec allows browsers to turn it off. If you want browsers to implement that, file bugs.

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.

[Stomme poes]

We have an open bug about fixing keyboard access with the color picker. Is the jump thing still reproducible?

I had alerted Bruce to both the keyboard thing and the jumping thing. My current Opera was jumping but it's been bugging me for months now to update so I did before testing again. It seems fixed though I'm going to try on the other machine where it jumped first, but last test was on 11.62.

If you could elaborate a bit on the e-commerse use case (something concrete like "user wants to buy a T-shirt that is available in three colors" or whatever) I could maybe file a spec bug asking for supporting a <select>-like color picker.

Thinking about it, the current technique of coloured checkboxes seems better. So long as they are actually checkboxes. It's just that e-commerce was my first thought. I otherwise have no idea why we'd have a special input type for selecting any colour in existence since it seems a very narrow use case.

Also surprised that the CSS colour names (which are all mapped to specific #hex numbers) aren't counted. Say if someone types in "red", that #ff0000 would be filled in. And while I like #hex better than other types, I've heard people ask why no rgb or hsl or whatever instead. I assume it just made sense from a spec-writing point of view to pick something now and wait for people to suggest others after there's something working.

I assume whoever introduced it to the spec knew of a good one. I'd like to hear it.

Hm, thinking, I came up with another one: sites like Twitter where users can personalise their own pages, you have the option of selecting a background colour. I think that one would pop up a colour wheel, probably with Javascript since it worked on many browsers. Maybe that was what the submitter was thinking?

That other browsers hadn't implemented the color picker yet doesn't seem to be a problem with the spec.

More that a browser not implementing a spec should *never* interfere with a user being able to use [the input]. See, browsers who don't support input type=email have no issues, and therefore were much safer in my book. It degraded better.

In most cases you could use input:read-write { ... }. It matches text, url, email, password, the date/time controls, and number, if it isn't readonly or disabled.

Hm, :read-write sounds like what I want, the question is does that support come and go with browser support for various input types?

I may use this for something I build where IE7 and 8 are not an issue. That was actually another issue I ran into: while IE7+ supports input[type=text], if you use a new type that IE doesn't support, while the "default" is "text", that doesn't seem to "count" for CSS or Javascript. Must only be browser behaviour. I ran in to the same thing when I had inputs who didn't list any type at all (again, since "text" was to be the default). The defaults weren't selectable criteria.
So that was another reason for either dropping styling in older browsers + IE, or using classes, and regexing in Javascript. I'll have to see now if these "states" have a JS equivalent.

It's more typing, but you don't need to worry about performance here, I'm pretty sure.

That's good to hear. Kangax has been doing some tests on selectors and things anyway, we're waiting for another blog post :)

Do you want to select readonly/disabled fields as well?

For usability reasons I generally do *not* give those the same styling. It should be visually obvious that the input is different in some way. But if I did I assume I'd just comma-separate-add the :read-only one as well?

For autofocus, the spec allows browsers to turn it off. If you want browsers to implement that, file bugs.

Will do. Ever try to use a page new to you while you're using a screen magnifier or a screen reader? Totally lost. Yet once a user is used to a page (like a search engine, or LinkedIn) they may want the autofocus... should be browser-side settings like font-size.

[zcorpan]

I had alerted Bruce to both the keyboard thing and the jumping thing.

OK, thanks!

Thinking about it, the current technique of coloured checkboxes seems better.

Great.

Also surprised that the CSS colour names (which are all mapped to specific #hex numbers) aren't counted. Say if someone types in "red", that #ff0000 would be filled in.

That's allowed. It's just UI. The browser could show a text field, allow the user to type in "red" or "slightly darker gray than santa's beard" and map it to a color. The hex value is just what gets exposed to JS and what gets submitted to the server, so that the author only needs to deal with simple hex values.

Hm, thinking, I came up with another one: sites like Twitter where users can personalise their own pages, you have the option of selecting a background colour.

That seems to be a reasonable use case for type=color, sure.

More that a browser not implementing a spec should *never* interfere with a user being able to use [the input]. See, browsers who don't support input type=email have no issues, and therefore were much safer in my book. It degraded better.

It would be fine if the browser didn't implement validation of the field. Then it would act just like type=text. So, to be a bit more accurate: that some browsers screw up the spec's back compat story by shipping partial implementations is a problem with those browsers, not with the spec.

Hm, :read-write sounds like what I want, the question is does that support come and go with browser support for various input types?

If :read-write is implemented per spec, then it should apply for unsupported controls that fall back to type=text. I don't know what support :read-write has in browsers, though.

That was actually another issue I ran into: while IE7+ supports input[type=text], if you use a new type that IE doesn't support, while the "default" is "text", that doesn't seem to "count" for CSS or Javascript.

That's per spec.

I'll have to see now if these "states" have a JS equivalent.

The .type property should give you the used state.

For usability reasons I generally do *not* give those the same styling. It should be visually obvious that the input is different in some way. But if I did I assume I'd just comma-separate-add the :read-only one as well?

No, :read-only matches all elements that :read-write doesn't match, per spec, so e.g. buttons would match :read-only. Maybe not the most useful thing in the world, but it's what the spec currently requires.

Will do.

Thanks.

[Stomme poes]

The .type property should give you the used state.

Well the checked state, for example, is input.checked. So I'm wondering if updated JS engines will recognise something like input.optional for example.

[zcorpan]

Well the checked state, for example, is input.checked. So I'm wondering if updated JS engines will recognise something like input.optional for example.

I thought you were talking about the state of the type attribute. There's no ".optional" in the spec. What would you want it for? (BTW this is actually unrelated to the JS engine; it's just DOM stuff.)

[deathshadow60]

I thought you were talking about the state of the type attribute. There's no ".optional" in the spec.

It is in the spec... just not under the normal psuedo-classes.
http://www.w3.org/TR/css3-ui/#pseudo-required-value

Don't worry, I missed those too on that new CSS3 quiz on the home page because they're not listed with the other psuedo-classes and instead are in some other module that I didn't even know existed -- when I thought I had just read the entire spec beginning to end looking FOR these types of things; just part of why I hate the specification texts; complete disorganized MESS where you can't find a blasted thing... which is why for a decade and a half (or more) we've had to have things like the W3Schools, the Sitepoint HTML/CSS reference, or the WDG HTML reference to actually make sense out of what can only be described as a close cousin to legalese. It's like the old joke "You had to go to college to write something this bad"

:default, :required, ptional, :valid, :invalid, :in-range, ut-of-range, :read-only, :read-write, -- they should at least be mentioned with the other psuedo-classes.