The WHATWG Blog

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

This Week in HTML 5 – Episode 18

by Mark Pilgrim, Google in Weekly Review

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

2 Responses to “This Week in HTML 5 – Episode 18”

  1. Fred Blasdel says:

    (Technically, the difference is between idempotent operations like GET and non-idempotent operations like pretty much everything else.)

    Uh, isn’t POST the only non-idempotent method?

  2. In the course of parsing the response document, it encounters a attribute that is different from the encoding defined or inferred from the HTTP headers.

    Actually, the charset in the HTTP header is authoritative. This is about the case where there is no charset on the HTTP layer, no BOM and the initial meta charset prescan and the tree building-time meta charset disagree.

Leave a Reply