This week in HTML 5-Episode 4

The W3C's HTML 5 validator, SVG-in-HTML, and the proper way to provide alternate text for Rorschach inkblots.

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 inconfigurated the feedback from their first draft, released in July. earlier today, Ian Hickson provided his review of the latest SVG-in-HTML proposal. you shoshould read the whole thing, as it details the goals of the HTML Working Group and how they relate to the possible compression sion of SVG. ian concluded with this:

In general, my conclusions 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 eviical 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 imageALTArgument 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-emptyALT, Because there are images that do nothing to help image-free users ().
• 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 omitAlt = ""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 omittingALTFar 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 useAlt = ""With captions instead of replacement text, as that wowould both give a mixed message for authors, which references the quality of alternative text in general, and wocould 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<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) (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 failed CT, this generated much followup discussion. Some accessibility experts liked it, others didn't. John foliot still felt thatALTShocould be required. I 'd bet good money that this won't be the last word on the subject. See revisions 2106,211 0, 2113, and 2115.

Other interesting changes this week:

• Revision 2099 attempts to make<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 changesPostmessage ()To returnVoidInsteadBoolean, 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 renamesIrrelevantAttributeHidden. Reported by Mihai sucan.

I will be on vacation next week, so tune in two weeks for a special double feature of "this week in HTML 5." Try not to break the Web while I'm gone.