The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Archive for the ‘Weekly Review’ Category

Next Entries »

This Week in HTML 5 – Episode 4

Thursday, August 28th, 2008

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 alt far 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 used alt="" 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:

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.

Posted in Weekly Review | 4 Comments »

This Week in HTML 5 – Episode 3

Friday, August 22nd, 2008

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 biggest news this week is the birth of the event loop.

To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section.

... An event loop has one or more task queues. A task queue is an ordered list of tasks, which can be:

Events

Asynchronously dispatching an Event object at a particular EventTarget object is a task.

Parsing

The HTML parser tokenising a single byte, and then processing any resulting tokens, is a task.

Callbacks

Calling a callback asynchronously is a task.

Using a resource

When an algorithm fetches a resource, if the fetching occurs asynchronously then the processing of the resource once some or all of the resource is available is a task.

Reacting to DOM manipulation

Some elements have tasks that trigger in response to DOM manipulation, e.g. when that element is inserted into the document.

The purpose of defining an event loop is to unify the definition of things that happen asychronously. (I want to avoid saying "events" since that term is already overloaded.) For example, if an image defines an onload callback function, exactly when does it get called? Questions like this are now answered in terms of adding tasks to a queue and processing them in an event loop.

The other major news this week is the addition of the hashchange event, which occurs when the user clicks an in-page link that goes somewhere else on the same page, or when a script programmatically sets the location.hash property. This is primarily useful for AJAX applications that wish to maintain a history of user actions while remaining on the same page. As a concrete example, executing a search of your messages in GMail takes you to a list of search results, but does not change the base URL, just the hash; clicking the Back button takes you back to the previous view within GMail (such as your inbox), again without changing the base URL (just the hash). GMail employs some nasty hacks to make this work in all browsers; the hashchange event is designed to make those hacks slightly less nasty. Microsoft Internet Explorer 8 pioneered the hashchange event, and its definition in HTML 5 is designed to match Internet Explorer's behavior.

Other interesting changes this week:

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 4 Comments »

This Week in HTML 5 – Episode 2

Thursday, August 14th, 2008

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 biggest news this week is revision 2020, which standardizes the navigator object:

The navigator attribute of the Window interface must return an instance of the Navigator interface, which represents the identity and state of the user agent (the client), and allows Web pages to register themselves as potential protocol and content handlers.

Currently, HTML 5 defines four properties and two methods:

This is only a subset of navigator properties and methods that browsers already support. See Navigator Object on Google Doctype for complete browser compatibility information.

Next up: Content-Language. No, not the HTTP header, not even the <html lang> attribute, but the <meta> tag! As reported by Henri Sivonen,

It seems that some authoring tools and authors use <meta http-equiv='content-language' content='languagetag'> instead of <html lang='languagetag'>.

This led to revision 2057, which defines the <meta> http-equiv="Content-Language"> directive and its relationship with lang, xml:lang, and the Content-Language HTTP header.

In the continuing saga of the alt attribute, the new syntax for alternate text of auto-generated images (which I covered in last week's episode) has generated some followup discussion. Philip Taylor is concerned that it will increase complexity for authoring tools; others feel the complexity is worth the cost. James Graham suggested a no-text-equivalent attribute; similar proposals have been discussed before and rejected.

Switching to the new Web Workers specification (which I also covered last week), Aaron Boodman (one of the developers of Google Gears) posted his initial feedback. This kicked off a long discussion and led to the creation of the Worker object.

Other interesting changes this week:

Administrivia: "This Week in HTML 5" now has its own feed.

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 3 Comments »

This Week in HTML 5 – Episode 1

Wednesday, August 6th, 2008

Welcome to a new semi-regular column, "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 biggest news is the birth of the Web Workers draft specification. Quoting the spec, "This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism." This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.

Also notable this week: even more additions to the Requirements for providing text to act as an alternative for images. 4 new cases were added:

  1. A link containing nothing but an image
  2. A group of images that form a single larger image
  3. An image not intended for the user (such as a "web bug" tracking image)
  4. Text that has been rendered to a graphic for typographical effect

Additionally, the spec now tries to define what authors should do if they know they have an image but don't know what it is. Quoting again from the spec:

If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just "{}"), then even the kind of image being shown is not known.

  • If the image is available, the element represents the image specified by the src attribute.
  • If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).

See also: revision 1972, revision 1976, revision 1978, revision 1979, Images and alternate text.

Other interesting changes this week:

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Processing Model, Weekly Review, WHATWG | 21 Comments »

Next Entries »