Wednesday, April 29th, 2009

Birth of the datagrid element in HTML 5

Category: HTML, Standards

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

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:

Keyword Description
text Simple text.
editable Editable text.
checkable Text with a check box.
list A list of values that the user can switch between.
progress A progress bar.
meter A gauge.
custom 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.

Posted by Dion Almaer at 4:26 am

4.5 rating from 29 votes


Comments feed TrackBack URI

I read this over on the WHATWG blog. The one thing that would help me to understand what this element is actually for is an example along with a comparison with the table element. As it is it looks like we now have two elements for tabular data. Would anyone care to point to or provide a little more illumination?

Comment by dzr — April 29, 2009

The most important difference between the table and the datagrid elements, is that the datagrid element will support a specific API (in JavaScript) with which we can do useful things. The API definition is not ready yet, but there would be things like a DataProvider, built-in sorting and some other things for which we normally need external JavaScript libraries. The table element will miss all these.

Those of use that have ever tried a XUL datagrid element should understand the differences. An example of a datagrid element in Firefox is the bookmark list that appears when pressing CTRL+B. If that sort of functionality will be built into the datagrid elements, then that is great news.

Also, I believe it would be much easier to traverse the rows in a datagrid element than in a table. There are complex situation with lots of colspans and rowspans which are very hard to query. In the datagrid element a row may have child rows, whereas in a table a row may have a table with other rows.

I hope the DataProvider will be smart enough so that it knows how to map a JSON structure to a datagrid structure.

Comment by igstan — April 29, 2009

I’m wondering why this wasn’t accomplished by enhancing the capabilities of a regular .

My thoughts:
1) A less capable in terms of structure. The equivalent of is just column labels, which are just Strings. No colspan or rowspan. Nothing corresponding to .

2) Lots of convenience. Standardizing loading data dynamically and sorting is a great thing. Child rows are OK if you’re building trees or hybrid tree-grids, and the equivalent in a is cumbersome.

3) Columns can be visible or invisible, but not rows. In a , the reverse is true. Rows are easy to hide, columns difficult. It would be nice to extend the “visible” attribute to the datagrid row. This would be useful for “search within results” type scenarios. I call it “filtering” in my applications.

4) I would like to see some thought put towards data export, or even printing, especially considering the dynamic loading data model. Is there a way to get or print all the data, or a flag to indicate that the user isn’t allowed to do that?

Comment by JonathanLeech — April 29, 2009

So this guy didn’t take his CS101 course seriously, what a pity.

> data is structured as a set of rows representing a tree, each row being split into a number of columns

An n-ary tree (a rose tree) is implemented using trivial nested lists. Lists themselves can be viewed as a degenerate case for a tree. If you really need an index-based access, that’s easy with linked lists, too. If you need constant-time index-based access, then you don’t need a tree, perhaps. You can amortize access time by utilising finger trees, though.

> Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices.

If you want to navigate with a focus point, you use a zipper. It’s remarkably simple and leads to code that is easy to understand and maintain.

Comment by chiaroscuro — April 29, 2009


Comment by Darkimmortal — April 30, 2009

I’m a little concerned about this list of types.
First, it seems to describe more how the data is rendered than its type. Text, for example, editable or not, is still text. That it is editable is more like state and should probably be settable at the cell level rather than at the column level.
Second, the list of types seems pretty arbitrary: why have progress and meter but no numbers or dates? Should HTML in general be in the business of defining a type system? (otoh the new input types are quite useful)
Finally, it seems to me like there are many ways to implement a data grid and it may be presumptuous from WhatWG to believe they can get it “right” because there are so many ways to get it right or wrong. The current status quo where libraries implement more opinionated grids on top of the existing table semantics doesn’t seem that wrong to me.
What am I missing? Why is this necessary?

Comment by BertrandLeRoy — April 30, 2009

Leave a comment

You must be logged in to post a comment.