This Week in HTML 5 – Episode 18
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
inputelement 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'sindeterminateDOM 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
indeterminateDOM attribute is set to true. TheindeterminateDOM 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:
- A user fills out a form and presses the submit button.
- The browser POSTs a form and begins parsing the response.
- 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:
- r2672 states that relative URLs in CSS in HTML documents are not reresolved when the base URL of the HTML document changes. This is just one of those incredibly weird things that web authors do that just makes you want to strangle them en-masse and scream "DON'T DO THAT!" But they do do it -- God knows why -- and it has been a source of pain for browser vendors because no standard has ever defined what they should do in this situation, so naturally they all do something different. [Background: Issues concerning the <base> element]
- r2674 defines a way for web authors to include documentation inside
<script src>elements -- that is, inline documentation for external scripts. - r2679 adds a number of browser interface elements to the HTML 5 spec, including
window.locationbar,window.menubar,window.personalbar,window.scrollbars,window.statusbar, andwindow.toolbar. These previous undefined properties are already supported by all major browsers except Internet Explorer.
Tune in... er, in a few hours... for another exciting episode of "This Week in HTML 5."
Uh, isn’t POST the only non-idempotent method?
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.