The WHATWG Blog

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

Author Archive

« Previous Entries
Next Entries »

This Week in HTML 5 – Episode 21

Tuesday, February 10th, 2009

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 more major work on the non-normative section on rendering HTML documents, including a lot of reverse-engineered documentation of legacy (invalid) attributes that users expect browsers to support.

In addition, one major section was dropped from HTML 5 this week: an algorithm for determining what object is under the cursor (presuming, of course, that the cursor is within the region of the screen which contains an HTML document, and the current context has a screen, and the current context has a cursor). Ian Hickson has announced on www-style that, in accordance with that group's consensus, the algorithm would be better maintained in a future CSS specification.

Around the web:

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 20

Tuesday, February 3rd, 2009

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 beginning of the non-normative section on rendering HTML documents. For those of you not up on spec-writing lingo, "non-normative" means "you can ignore this and still claim to be in compliance with the specification." It's advice, not commands. On the other hand, it's generally useful advice, so ignoring it completely is probably not in your best interests.

Currently, the rendering section includes advice on

Scrolling through the rest of the (mostly empty) rendering section shows lots of potential for future advice on form controls, data grids, favicons, and even the <marquee> element.

Rendering-related revisions: r2734, r2735, r2736, r2737, r2738.

Switching back to the normative parts of the spec, we have r2720, which makes the outerHTML property and the insertAdjacentHTML() method work in XHTML. For the purposes of this discussion — indeed, for the purposes of the entire HTML 5 specification — "XHTML" means "content served with a Content-Type: application/xhtml+xml". In addition, the section The XHTML Syntax has been entirely reorganized and rewritten to consolidate the rules for parsing and serializing XHTML documents and fragments. [Background: Re: outerHTML/insertAdjacentHTML in XML mode]

Other interesting tidbits this week:

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 19

Friday, January 30th, 2009

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. Despite it being almost February already, this episode will focus on changes and discussion from the week of January 19th. Normal weekly updates will resume on Monday.

There are 3 pieces of big news for the week of January 19th. Big news #1: r2692, a major revamp of the way application caches are defined. Application caches are the heart of the offline web model which can be used to allow script-heavy web applications like Gmail to work even after you disconnect from the internet. Here is the new definition of how application caches work:

Each application cache has a completeness flag, which is either complete or incomplete.

An application cache group is a group of application caches, identified by the absolute URL of a resource manifest which is used to populate the caches in the group.

An application cache is newer than another if it was created after the other (in other words, application caches in an application cache group have a chronological order).

Only the newest application cache in an application cache group can have its completeness flag set to incomplete, the others are always all complete.

Each application cache group has an update status, which is one of the following: idle, checking, downloading.

A relevant application cache is an application cache that is the newest in its group to be complete.

Each application cache group has a list of pending master entries. Each entry in this list consists of a resource and a corresponding Document object. It is used during the update process to ensure that new master entries are cached.

An application cache group can be marked as obsolete, meaning that it must be ignored when looking at what application cache groups exist.

A Document initially is not associated with an application cache, but steps in the parser and in the navigation sections cause cache selection to occur early in the page load process.

Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource.

The end result of this major work is actually pretty similar to how application caches worked before, but there were some edge cases (such as handling 404 errors when fetching the application manifest) which are now handled in a sane fashion. It also paved the way for r2693, which makes it possible for application caches to become "obsolete" (meaning they must be ignored when deciding which caches exist).

Big news #2: r2684, which redefines the on* attributes in a way that doesn't suck quite as much. Also, it defines the widely used (but poorly understood) onerror attribute in a way that matches what browsers actually do with it. Here is the meat of it:

All event handler attributes on an element, whether set to null or to a Function object, must be registered as event listeners on the element, as if the addEventListenerNS() method on the Element object's EventTarget interface had been invoked when the event handler attribute's element or object was created, with the event type (type argument) equal to the type described for the event handler attribute in the list above, the namespace (namespaceURI argument) set to null, the listener set to be a target and bubbling phase listener (useCapture argument set to false), the event group set to the default group (evtGroup argument set to null), and the event listener itself (listener argument) set to do nothing while the event handler attribute's value is not a Function object, and set to invoke the call() callback of the Function object associated with the event handler attribute otherwise.

The listener argument is emphatically not the event handler attribute itself.

When an event handler attribute's Function objectw is invoked, its call() callback must be invoked with one argument, set to the Event object of the event in question.

The handler's return value must then be processed as follows:

If the event type is mouseover

If the return value is a boolean with the value true, then the event must be canceled.

If the event object is a BeforeUnloadEvent object

If the return value is a string, and the event object's returnValue attribute's value is the empty string, then set the returnValue attribute's value to the return value.

Otherwise

If the return value is a boolean with the value false, then the event must be canceled.

The Function interface represents a function in the scripting language being used. It is represented in IDL as follows:

[Callback=FunctionOnly, NoInterfaceObject]
interface Function {
any call([Variadic] in any arguments);
};

The call(...) method is the object's callback.

In JavaScript, any Function object implements this interface.

Big news #3: r2685 and r2686 defines a whole slew of important events that are fired on the Window object, including onbeforeunload, onerror, and onload. Previously, some of these were defined on the <body> element, which didn't actually match current browser behavior.

The following are the event handler attributes that must be supported by Window objects, as DOM attributes on the Window object, and with corresponding content attributes and DOM attributes exposed on the body element:

onbeforeunload

Must be invoked whenever a beforeunload event is targeted at or bubbles through the element or object.

onerror

Must be invoked whenever an error event is targeted at or bubbles through the object.

Unlike other event handler attributes, the onerror event handler attribute can have any value. The initial value of onerror must be undefined.

The onerror handler is also used for reporting script errors.

onhashchange

Must be invoked whenever a hashchange event is targeted at or bubbles through the object.

onload

Must be invoked whenever a load event is targeted at or bubbles through the object.

onmessage

Must be invoked whenever a message event is targeted at or bubbles through the object.

onoffline

Must be invoked whenever a offline event is targeted at or bubbles through the object.

ononline

Must be invoked whenever a online event is targeted at or bubbles through the object.

onresize

Must be invoked whenever a resize event is targeted at or bubbles through the object.

onstorage

Must be invoked whenever a storage event is targeted at or bubbles through the object.

onunload

Must be invoked whenever an unload event is targeted at or bubbles through the object.

Other interesting tidbits from the week of January 19th:

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 18

Friday, January 30th, 2009

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. Despite it being almost February already, this episode will focus on changes and discussion from the week of January 12th. (Very little constructive progress was made between the 1st and the 12th.) I'll follow up with another summary for the week of January 19th, then I'll resume normal weekly updates on Monday.

The big news for the week of January 12th is r2633, which defines the indeterminate attribute on form controls.

The input element represents a two-state control that represents the element's checkedness state. If the element's checkedness state is true, the control represents a positive selection, and if it is false, a negative selection. If the element's indeterminate DOM attribute is set to true, then the control's selection should be obscured as if the control was in a third, indeterminate, state.

The control is never a true tri-state control, even if the element's indeterminate DOM attribute is set to true. The indeterminate DOM attribute only gives the appearance of a third state.

Internet Explorer and Safari already support the indeterminate attribute.

The other news I want to highlight this week -- just because this sort of weirdness tickles me -- is r2616, which tries to tackle the following difficult situation:

  1. A user fills out a form and presses the submit button.
  2. The browser POSTs a form and begins parsing the response.
  3. In the course of parsing the response document, it encounters a <meta charset> attribute that is different from the encoding defined or inferred from the HTTP headers.

If this were the response from a GET request, the browser might re-request the page so it could restart parsing with the new character encoding. But doing that after a POST would be like double-submitting the form, which could have serious consequences on the back end. (Technically, the difference is between idempotent operations like GET and non-idempotent operations like pretty much everything else.) So browsers should never re-request the page after a POST, and they'll just have to muddle through as best they can with the character encoding they have. [bug 6258]

Other interesting tidbits that week:

Tune in... er, in a few hours... for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 2 Comments »

This Week in HTML 5 – Episode 17

Tuesday, December 30th, 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 a major revamp of table headers, following up from the last major edits last March. Ian summarizes the most recent round of changes:

  • Header cells can now themselves have headers.
  • I have reversed the way the algorithm is presented, such that it starts from a cell and reports the headers rather than generating the list of headers for each cell on a header-by-header basis.
  • If headers="" points to a <td> element, the association is set up, but I have left this non-conforming to help authors catch mistakes.
  • Header cells that are automatically associating do not stop associating when they hit equivalent cells unless they have also hit a <td> first.
  • The "col" and "row" scope values now act like the implied auto value except that they force the direction.
  • Empty header cells don't get automatically associated.
  • I have removed the wide header cell heuristic.
  • I have made headers="" use the same ID discovery mechanism as getElementById(), to avoid implementations having to support multiple such mechanisms.
  • Finally, I have made the spec define if a header is a column header or a row header in the case where scope="" is omitted.
  • I haven't added summary="" on table; nothing particularly new has been raised on the topic since the last times I looked at this.

Accessibility advocates are disappointed by the continued non-inclusion of the summary attribute. Their reasoning is that "the summary attribute is a very, very practical and useful attribute," despite their own user testing that shows otherwise. As Ian put it, "I am hesitant to include a feature like summary="" when all evidence seems to point to it being widely misused by authors and ignored by the users it intends to help." As with all issues, this is not the final word on the matter, but it's where we stand today.

In other news, r2566 addresses a very subtle issue with fetching images. The problem stems from the following (arguably pointless) markup: <img src=""> A fair number of web pages actually try to declare an image with an empty src attribute. According to the HTTP and URL specifications, this markup means that there is an image at the same address as the HTML document -- a theoretically possible but highly unlikely scenario. Internet Explorer apparently catches this mistake and just silently drops the image. Other browsers do not; they will actually try to fetch the image, which results in a "duplicate" request for the page (once to successfully retrieve the page, and again to unsuccessfully retrieve the image).

Boris Zbarsky, a leading Mozilla developer, states

We (Gecko) have had 28 independent bug reports filed (with people bothering to create an account in the bug database, etc) about the behavior difference from IE here. That's a much larger number of bug reports than we usually get about a given issue. I can't tell you why this pattern is so common (e.g. whether some authoring frameworks produce it in some cases), but it seems that a number of web developers not only produce markup like this but notice the requests in their HTTP logs and file bugs about it.

r2566 addresses the issue by special-casing <img src> to allow browsers to ignore an image if its fetch request would result in fetching exactly the same URL as its HTML document:

When an img is created with a src attribute, and whenever the src attribute is set subsequently, the user agent must fetch the resource specifed by the src attribute's value, unless the user agent cannot support images, or its support for images has been disabled, or the user agent only fetches elements on demand, or the element's src attribute has a value that is an ignored self-reference.

The src attribute's value is an ignored self-reference if its value is the empty string, and the base URI of the element is the same as the document's address.

Other interesting tidbits this week:

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

Posted in Weekly Review | 12 Comments »

« Previous Entries
Next Entries »