The WHATWG Blog

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

This Week in HTML 5 – Episode 31

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.

This big news this week is the <datagrid> element. This is a brand spanking new element introduced in r2962.

In the datagrid data 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 RowID interface.

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:

KeywordDescription
textSimple text.
editableEditable text.
checkableText with a check box.
listA list of values that the user can switch between.
progressA progress bar.
meterA gauge.
customA 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.

Tune in next week for another exciting episode of "This Week in HTML 5."

8 Responses to “This Week in HTML 5 – Episode 31”

  1. This big news this week is the <datagrid> element. This is a brand spanking new element introduced in r2962.

    Actually, it has existed since at least 2005. It was just rewritten.

  2. [...] Mark Pilgrim has nicely discussed the new HTML 5 datagrid element on his latest This Week in HTML 5: [...]

  3. Mark,

    Has there been any talk about how content could be mapped to a datagrid for client-side dynamically generated content? I think this will be a key issue in the future.

    We spent a lot of time working on generic protocols for mapping tree-based content (XML, js objects etc) directly to our own pseudo implementation of datagrids.

    I’m happy to share the results of our work, if you think it could be useful.

    D.

  4. While some of the functionality provided by the datagrid element seems useful I’m still not sure I understand why we have redundent elements. I haven’t taken a detailed look at the spec but it seems we could just extend the table element to have the functionality of the datagrid.

    One of the things I like about HTML is that it is fairly simple. Anybody can pick up the basics in about 5 minutes. Having two elements that each do basically the same thing but are slightly different seems to go against that.

    Also introducing a new element rather than extending an existing element seems like it would cause more frustration in compatibility. It would be years before I could use a datagrid element. On the other hand if you did something like:


    <th sortable="true">Column Head</th>

    This would allow browsers that support a sortable table to implement it and browsers that don’t support it still display a table. It just gracefully degrades to a non-sortable table.

    Just my two cents.

  5. Jerry Dawson says:

    I agree with Mr. Anderson, in that it does seem redundant. However, a standard table does not support tree style data. You would also have to add something like :

    <tr level=”2″>
    <td>child of the previous row and should be indented.</td>
    </tr>

  6. [...] Datagrid was a kind of interactive table thingie—think spreadsheets. [...]

  7. [...] well-documented anywhere. It was added to HTML5 earlier this year (and covered in episode 12 and episode 31). The spec text borrows heavily from this incredibly detailed documentation posted to the WHATWG [...]

  8. David Peers says:

    This blog helped me in narrowing down some issues with the latest release, Why do they always seem to leave out vital information when they release a new version? It may be minor to them but not to me. I’m sure we’re not alone either.

Leave a Reply