Moved over to HTML5

Sometimes they really screw up words. Generally you either hear a word mis-pronounced enough in the voice you usually use that you get used to it, or you hear something weird and you go back and spell the word out (and see if it’s in upper or lower case) to figure out what it was.

How a word is pronounced depends on the voices you have, the synth you have, and the language (and how well that language had been built). Like, I was getting pretty exited that NVDA was getting a new Dutch voice, but the guy who was helping on it, I’d have to ask him how that’s going.

You ought to hear VoiceOver say “Firefox”, it’s creepy. Veeerevux. Also wieeeb developers. Lawlz.

Anyway I don’t think how to pronounce a word belongs in the HTML. If it’s a standard dictionary word it should be handled on the AT side.

Not sure why HTML10 would need that added, we already have Schema :confused: which I would only ever use if a client told me they had software that actually did something with it, since the whole adding all that itemscope prop etc stuff just seems like a lot of extra bytes for a reader who doesn’t exist.

Microformats are outside the scope of HTML though. Which may be a good thing. With attributes like the data-foo ones where browsers increasingly don’t do anything with the attribute at all, but it’s there for someone else (Javascript, desktop software) who may also be reading the HTML, it could open up possibilities (and confusion) and leave HTML alone.

So anyway, back on topic: who else uses HTML5 stuff, and which stuff does you uses?


Do you mean the American version, or Dutch?

I don’t think how to pronounce a word belongs in the HTML. If it’s a standard dictionary word it should be handled on the AT side.

Do you mean you don’t like elements like <abbr>? I think it’s as useful to be able to mark up an acronym as such as it is to mark up a date, or whatever. It can be quite embarrassing to find—after reading a word like PNG on the web for years—that many an one pronounces it as “ping”.

(I also now find myself compelled to refer to Australia’s nearest neighbor as “Ping”, which doesn’t help. :shifty:)[/ot]

Some other things I’ve used are that we haven’t yet mentioned:

File API, for drag/drop uploads as well as image previews client-side before upload - You can progressively enhance a normal file input and make it a lot more responsive.
contenteditable Edit any HTML element - Doesn’t make sense without js but adds a few possibilities.

I can’t remember anymore which language it was I heard it in! Macs come with English so if you want Dutch you have to go get that language pack yourself even if you bought a Dutch Mac with Dutch as the default OS language and everything. A failing on their part I think. It was a demo by Bram Duvigneau where his JAWS read English so I think his VO did too.

<abbr> is kinda useless so I rarely use it. If a word needs a tooltip to explain it then I probably need a glossary or the full name after the term in parens().
And I still say pee en gee. For both the file format and the country. Ping’s already taken in my vocab for what I do to google to check I have internets :)[/ot]

I am not sure if you are joking, but I will say you are incorrect here. Dragon Naturally Speaking has actually improved leaps and bounds. I first encountered Dragon in ~2000-2001, and individuals with speech impairments could not use it. Those people could use Dragon in ~2004 with 40-80 hours of training at 30-50% accuracy. I know somebody with a medium to severe speech impairment, and was able to pick up Dragon 10, train for 20-40 minutes, and got ~90% accuracy. If that is not improvement, I want to see what would qualify as such. I haven’t looked at the built-in engine that comes with Windows 7, but most people who are AT Consultants, like myself, would never recommend using windows built-in components, unless there is no other option ($$$).

What I would need to know about Siri and whatever it is called on Android is does it remember what you say or is it a one-off everytime. I don’t mean for tracking purposes. One of the benefits of Dragon, it actually learns as you talk.

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

What do you want to use it for, specifically?

I don’t know what you’re talking about here. :slight_smile:

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

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

Nope. :slight_smile:

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

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

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

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. :slight_smile:

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.

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.

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

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.

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?

For autocomplete, see

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


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.

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?

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.

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.

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

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?

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.

OK, thanks!


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.

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

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.

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’s per spec.

The .type property should give you the used state.

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.


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.

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

It is in the spec… just not under the normal psuedo-classes.

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, :optional, :valid, :invalid, :in-range, :out-of-range, :read-only, :read-write, – they should at least be mentioned with the other psuedo-classes.