W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2006

[whatwg] Enhanced data tables

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 19 Sep 2006 23:39:30 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0609192333150.21538@dhalsim.dreamhost.com>
On Sat, 4 Dec 2004, Matthew Thomas wrote:
> On 4 Dec, 2004, at 6:32 AM, Afternoon wrote:
> > On 3 Dec 2004, at 17:18, Ian Hickson wrote:
> > ...
> > > From a practical standpoint the difference between a <table> and a data
> > > grid is that the table's data is all in a DOM content model, whereas the
> > > data grid can be dynamically populated from script, one row at a time, so
> > > that only the displayed portion need be in memory at any one time.
> 
> Could functions be devised to make populating (and depopulating) <table> 
> rows and columns easier than it is now, without inventing a new element 
> for such tables?

Not without further overloading the <table> element. The requirements for 
implementing <table> are already pretty onerous, with custom DOM 
interfaces, at least three rendering models, one of which is not formally 
defined anywhere, the second of which is only poorly defined, peculiar 
parsing requirements, etc.

By having a new element, which can wrap <table>, we can reuse the <table> 
semantics, while still allowing UAs to separate their <table> 
implementation from the new code neatly.

<table> is a very brittle element in terms of implementations -- it's a 
source of many quite complex bugs. Adding more complex code to <table> 
doesn't seem like a good idea.


> > > Another difference is that tables have a legacy of rendering 
> > > semantics which we can't do much about, whereas for the data grid we 
> > > want to be able to use GUI-specific native controls (or 
> > > native-looking controls) which have features such as clickable 
> > > column headers, draggable column separators, etc. Also, datagrids 
> > > are limited to text in each cell (with one icon per row), rows can 
> > > be selected, data can be marked as editable, etc.
> >
> > Indeed, a browser that assumed every <table> was data-bearing and 
> > should have controls displayed would be all but useless.
> 
> That's why I suggested those controls be displayed only for <th> 
> elements, not for every <table>.

I'm not convinced that this would be enough to avoid breaking assumptions 
made by existing Web pages. It also would, as mentioned above, require 
overloading of <table>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 19 September 2006 16:39:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:29 UTC