This Week in HTML 5 – Episode 8
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
clickevent 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
inputandchangeevents. Theinputevent occurs during typing in a form field (and therefore may trigger multiple times as the user types); thechangeevent 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."