Wednesday, December 10th, 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 disintegration of HTTP authentication from HTML forms (which was last week's big news). As I predicted, the proposal generated a healthy discussion, but a combination of security concerns and concerns about tight coupling ultimately did in the proposal.
In its place, r2470 includes the following conformance requirement to allow for the possibility of someone specifying such a scheme in the future (hat tip: Robert Sayre):
HTTP 401 responses that do not include a challenge recognised by the user agent must be processed as if they had no challenge, e.g. rendering the entity body as if the response had been 200 OK.
User agents may show the entity body of an HTTP 401 response even when the response do include a recognised challenge, with the option to login being included in a non-modal fashion, to enable the information provided by the server to be used by the user before authenticating. Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against authentication challenges included in other responses such as HTTP 200 OK responses, effectively allowing resources to present HTTP login forms without requiring their use.
Continuing with the web forms work, the <input> element has gained a new type: a color picker, marked up as <input type=color>. Browser vendors are encouraged to integrate this field with platform-native color pickers, as appropriate. As with all new input types, browsers that do not explicitly recognize the new type will default to a simple text field.
The <audio> and <video> API continues to churn rapidly. Implementors should probably ignore it altogether until it's been stable for two consecutive weeks. To wit: r2493 removes the pixelratio attribute, originally proposed to allow authors to override the display of videos known to be encoded with incorrect an aspect ratio. r2498 adds the playing event, fired when playback as started. r2489 drops the HAVE_SOME_DATA readyState. I will try to write up a comprehensive summary of this API once its stabilizes.
Other interesting tidbits this week:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review, WHATWG | 1 Comment »
Wednesday, October 8th, 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.
It's time to catch up on the myriad of changes to the HTML 5 spec. The big news this week is the continued merging of Web Forms 2 into HTML 5.
<button> [r2280]<select> [r2285, r2287, r2288, r2290]<input type="submit"> [r2269]<input type="reset"> [r2270]<input type="button"> [r2271]<input type="image"> [r2276]<input type="file">> [r2274]<input type="checkbox"> [r2257, r2258]<input type="radio"> [r2259]<input type="hidden"> [r2268]<input type="email"> [r2227]<input type="url"> [r2228, r2231, r2235]<input type="number"> [r2254]<input type="range"> [r2255]<input type="date"> [r2252]<input type="time"> [r2253]<input type="datetime"> [r2229, r2230, r2231, r2239, 2243, r2247, r2251]<input type="week"> [r2252]<input type="month"> [r2252]<input type="datetime-local"> [r2249]
In other news, Andy Lyttle wants to standardize one particular feature of <input type="search"> (which is already supported by Safari, but not standardized): placeholder text for input fields. The text would initially display in the input field (possibly in a stylized form, smaller font, or lighter color), then disappear when the field receives focus. Lots of sites use Javascript to achieve this effect, but it is surprisingly difficult to get right, in part because no one can quite agree on exactly how it should work. Mozilla Firefox displays the name of your current search engine in its dedicated search box until you focus the search box, at which point it blanks out and allows you to type. Safari's search box is initially blank (at least on Windows), and only displays the name of your default search engine after it has received focus and lost it again. Google Chrome's "omnibox" displays "Type to search", right-justified, even when the omnibox has focus, then removes it after you've typed a single character. Adding an <input placeholder> attribute would allow each browser on each platform to match their users' expectations (and possibly even allow end-user customization) of how placeholder text should work for web forms. Discussion threads: 1, 2, 3. So far, there is no consensus on whether this should be added to HTML 5, or what the markup would look like.
Other interesting changes this week:
- r2273 defines the
<input required> attribute.
- r2272 defines what it means to "activate" a form field, so that "clicking a button" and "setting focus to the button and pressing space" result in the same
click event being triggered.
- r2277 defines the
<input size> attribute, which controls the displayed size of the field (but not the length of the field's value, that's <input maxlength> [r2233]).
- r2278 defines the
<input pattern> attribute, which is an arbitrary regular expression against which the field's value should be matched.
- r2282 defines the
input and change events. The input event occurs during typing in a form field (and therefore may trigger multiple times as the user types); the change event triggers when a change is committed, even if typing was not involved (such as choosing files to upload with an <input type="file"> field.
- r2242 tweaks the definition of floating point numbers to allow specifying an exponent.
Around the web:
- Following up on last week's article on clickjacking, the security researcher who discovered (and named) it has posted details of his discovery. Short version: it's even worse than we thought, but vendors are working on it. Here's a proof-of-concept against Adobe Flash that, quite literally, spys on you (via your webcam) without the usual warning dialogs; here's Adobe's response. NoScript now offers enhanced protection against some clickjacking attack vectors.
- Anne van Kesteren gives an update on IE 8's support for HTML 5 and other emerging standards.
- Matt Ryall has a good article on HTML 5, headings and sections, which documents the differences between HTML 4 and 5's header elements. My personal opinion: I once wrote a 500 page book in Docbook, a non-HTML markup language for technical writers. Docbook 3 had separate elements for
<sect1>, <sect2>, <sect3>, &c, and it was a massive pain in the ass to cut-and-paste sections, or try to reuse them in different documents. Docbook 4 added a generic <section> element which can be nested indefinitely, and all those problems went away. Lots of web authors copy-and-paste HTML markup; anything that helps that "just work" is a good thing.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 6 Comments »
Tuesday, September 23rd, 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.
There is no big news this week. Work continued on last week's orgy of Web Forms-related check-ins. This week adds the <label> element and the jack-of-all-forms <input> element. [r2191, r2192, r2197, r2200, r2202, r2204, r2205, r2207, r2211, r2212, r2213, r2214, r2218, r2219, r2220, r2222, r2223]
Laura Carlson and others have begun to review the accessibility of multimedia on the web. Most accessibility discussions revolve around the needs of visually impaired users, but hearing impaired users are also important and too often ignored. There was a long discussion last month (and continuing into this month) about the accessibility implications of the <audio> and <video> elements for hearing impaired users. YouTube (owned by Google, my employer) recently announced support for captions on YouTube videos and published a tutorial on adding them to your own videos.
Ian Hickson (the HTML 5 editor) gave an interview about HTML 5 in which he reiterated his goal of having two independent, complete, interoperable implementations of HTML 5 by 2022. (By contrast, HTML 4.0 was "finalized" 11 years ago but still doesn't have two independent, complete, interoperable implementations.) This led to a mini-firestorm among bloggers who misunderstood "2022" as "the date when I can start using HTML 5 features." It bears repeating that the "2022" date has no significance at all for web developers. Most browser vendors are actively involved in HTML 5, several browsers are already shipping HTML 5 features, and developers who are holding their breath until 2022 are going to find themselves seriously behind the curve.
On that note, Brenton Strine asks a very good question: "Is there some place that documents the parts of HTML 5 that are already up and running? Can I use <canvas> or <video>? In which browsers? What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008?" On the video front, Mozilla will be shipping Ogg Theora support in Firefox 3.1. (You can read more about why Ogg matters.) Last year, Opera released experimental builds with Ogg Theora support, and they now have video-enabled builds on 3 platforms. The Wikimedia Foundation has a few Theora-encoded videos you can watch.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 6 Comments »