This Week in HTML 5 – Episode 31
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.
datagriddata model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns might be hidden in the presentation.
Each row can have child rows. Child rows may be hidden or shown, by closing or opening (respectively) the parent row.
Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices. Thus, the first row of a list is row "0", the second row is row "1"; the first child row of the first row is row "0,0", the second child row of the first row is row "0,1"; the fourth child of the seventh child of the third child of the tenth row is "9,2,6,3", etc.
The chains of numbers that give a row's path, or identifier, are represented by arrays of positions, represented in IDL by the
The root of the tree is represented by an empty array.
Each column has a string that is used to identify it in the API, a label that is shown to users interacting with the column, a type, and optionally an icon.
The possible types are as follows:
Text with a check box.
A list of values that the user can switch between.
A progress bar.
A canvas onto which arbitrary content can be drawn.
Each column can be flagged as sortable, in which case the user will be able to sort the view using that column.
Columns are not necessarily visible. A column can be created invisible by default. The user can select which columns are to be shown.
When no columns have been added to the
datagrid, a column with no name, whose identifier is the empty string, whose type is
text, and which is not sortable, is implied. This column is removed if any explicit columns are declared.
Each cell uses the type given for its column, so all cells in a column present the same type of information.
The other major change to the spec this week is the
<keygen> element. As I mentioned in episode 12, someone went to the trouble of documenting the
<keygen> element, and there has been a surprising amount of discussion about it in the past six months. Simply put, the keygen element represents a key-pair generator control. You include it in a
<form>. When your browser submits the form, the private key is stored in the local keystore, and the public key is packaged and sent to the server. [r2960]
Not much else went into the spec this week, but there's been a lot of interesting activity around the web.
- A new W3C Working Draft of HTML 5 is out. As I've mentioned before, this is just a snapshot of progress-to-date. By its very nature, it is out of date as soon as it's published, since the working group continues to progress while the webmaster gnomes are publishing.
- Also published: the latest draft of "HTML 5 differences from HTML 4", compiled by Opera's Anne van Kesteren.
- Mozilla bug 465007: "Harmonize content sniffing in HTML 5 and Firefox." The next version of Firefox will sniff images the way the HTML 5 specification recommends. I am still opposed to content sniffing on philosophical grounds, but philosophy doesn't get you very far on the open web, and documented heuristics are better than undocumented heuristics. And interoperable, documented heuristics are even better!
- Speaking of content sniffing, Adam Barth's [PDF] whitepaper, Secure Content Sniffing For Web Browsers, is an excellent read.
- Henri Sivonen's The Last of the Parsing Quirks is equally fascinating.
- Superset encodings [Re: ISO-8859-* and the C1 controlrange] is an incredibly detailed look into the insane world of character encoding.
- You can still help us review HTML 5! Your input is important!
Tune in next week for another exciting episode of "This Week in HTML 5."