This Week in HTML 5 - Episode 4
August 28th, 2008 by Mark Pilgrim, Google
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news this week is the birth of the W3C's experimental HTML 5 validator (announcement). It is based on Henri Sivonen's experimental HTML 5 validator, although there are still some integration bugs to shake out. Related discussion on Sam Ruby's blog.
SVG is back in the news. In a presentation to the Mozilla Corporation in December 2005, a Firefox developer asked me what I had against SVG. I replied, "I have nothing against SVG; make it work in HTML." Last week, Doug Schepers, on behalf of the SVG Working Group, reported that their SVG-in-HTML proposal was ready for another review, having incorporated the feedback from their first draft, released in July. Earlier today, Ian Hickson provided his review of the latest SVG-in-HTML proposal. You should read the whole thing, as it details the goals of the HTML Working Group and how they relate to the possible inclusion of SVG. Ian concluded with this:
In general, my conclusions are are [sic] somewhat negative:
- There are a lot of goals that aren't met.
- It seems to me that this proposal goes to great lengths to support some syntax (e.g. namespaces) despite evidence that doing so is not necessary, and it makes sacrifices regarding potential optimisations (like making the tokeniser case-insensitive, avoiding substring searches, avoiding attribute searches) despite evidence that browsers consider performance critical.
- It leaves some aspects quite poorly defined, such as how encoding errors are handled, exactly where parse errors are to be established as occuring, and how the XML parser is expected to interact with
document.write().- It rather poorly handles typical authoring mistakes such as copying and pasting half of an SVG or MathML fragment into an HTML page, or omitting namespace declarations altogether.
In other news, the image alt argument is finally over! Ha ha, just kidding. But Ian Hickson did summarize all of the proposed solutions to date:
- We can't require that every image have non-empty
alt, because there are images that do nothing to help image-free users (A).- We can't say that making a site like Flickr requires asking all users for alternative text, since users simply won't provide that data (B, B.1).
- We can't just omit
alt=""with nothing else, since then users of image navigation will get lost (B.2.i).- We can't use special syntax, since it hurts sites that care about accessibility more than anyone else, which just hurts the accessibility cause (B.2.ii.a, B.2.ii.b, B.2.ii.c).
- We can't introduce a new attribute because this will legitimise omitting
altfar too much, again hurting the accessibility cause, and any new attribute will likely be misused to the point of making the attribute useless, due to the copy-paste mentality of authors who don't understand the spec (B.2.iii.a, B.2.iii.b, .2.iii.c.I, B.2.iii.c.II, B.2.iii.c.III).- We can't just use
alt=""with captions instead of replacement text, as that would both give a mixed message for authors, reducing the quality of alternative text in general, and would make it harder to understand pages with a lot of images even if they usedalt=""correctly, if they sometimes had to use this technique (B.2.iv).- We can't require that all such images be links or be in a
<figure>, since both of these over-constrain the author and will likely just be requirements that are ignored (B.2.v, B.2.vi).- We don't want to have multiple levels of conformance because authors seem happy to aim for the lower level (as seen with HTML4 Transitional), and because just doing this still doesn't address the problem (we have to pick one of the other solutions for the "lesser" conformance class), and because this isn't necessarily something that is fixable (we want full conformance to be something that authors can always aim for) (B.3).
- We don't want to just say authors can punt on alternative text altogether, as that doesn't help accessibility (C).
- We don't want to not require alternative text at all, since in most cases alternative text is quite easy to add and massively helps non-image users (D).
- We don't want to ban alternative text as there is simply no other alternative for handling images these days (E).
As you might expect, this generated much followup discussion. Some accessibility experts liked it, others didn't. John Foliot still felt that alt should be required. I'd bet good money that this won't be the last word on the subject. See revisions 2106, 2110, 2113, and 2115.
Other interesting changes this week:
- Revision 2099 attempts to make the
<style scoped>content model clearer. Reported by Henri Sivonen. - Revision 2106 mentions how to provide alternate text for a Rorschach inkblot test. Seriously. Reported by Steven Faulkner.
- Revision 2117 changes
postMessage()to returnvoidinstead ofboolean, since "even if the worker is currently up and running whenpostMessageis called, there is no guarantee that the worker will run long enough to actually get to process the message." Reported by Jonas Sicking. - Revision 2119 renames the
irrelevantattribute tohidden. Reported by Mihai Sucan.
I will be on vacation next week, so tune in in two weeks for a special double feature of "This Week in HTML 5." Try not to break the web while I'm gone.
August 28th, 2008 at 20:35
Just for the record. I have never claimed to be an ‘accessibility expert’ that is a term reserved for people of Mark Pilgrim’s and Ben Millard’s stature, seriously.
August 29th, 2008 at 02:00
The Rorschach inkblot text addition for the alt tag will not, in my limited experience, pass WCAG 2 guidelines which finds fault with long alt descriptions. Why not make the alt for an inkblot simply “Rorschach inkblot”? The description in 2106 almost seems tongue-in-cheek.
September 2nd, 2008 at 13:11
[...] Mark Pilgrim’s This Week in HTML 5 Episode 4 comes to you with the weekly summary: The big news this week is the birth of the W3C’s [...]
October 14th, 2008 at 20:47
[...] phrase here is “as-yet-unknown technologies.” In that light, the recent SVG-in-HTML proposal (which I mentioned several weeks ago) is beside the point. The point of distributed extensibility is that it does not require approval [...]
December 22nd, 2008 at 01:04
[...] Extending HTML4 Forms: Web Forms 2.0 at the W3C Saved by TentenandNejilover on Mon 08-12-2008 This Week in HTML 5 - Episode 4 Saved by SiNPlE on Sun 07-12-2008 Forums:: Oracle sexing it up.. Saved by maddeli on Sat [...]