Re: [whatwg] Proposals for better support of Tables

[Pierre Dubois]

On Tue, Nov 6, 2012 at 2:21 PM, Ian Hickson  wrote:
>
> On Mon, 7 Feb 2011, Alexandre Morgaut wrote:
> >
> > The HTML Table API provides powerful attributes like:
> > - "scope"
> > - "headers"
> > - "colspan"
> > - "rowspan"
> >
> > All of them give informations about relationships between the table
> > cells, rows, and columns
> >
> > It would be very helpful if:
> >  - each "th" element could have a "cells" property which would be the
> > HTML Collection of each "td" they are heading

Use case: Draw a graphic based on a data table
* Like a pie chart, based on a sub-set of data contained in a data table.

An issue can be when the header cell cover and/or represent more than
one group (eg. multiple tbody from a column perspective and multiple
colgroup from a row perspective)

> >  - each "td" element could have a "headerCells" property which would be
> > the HTML Collection of each of their related "th"

Use case: Draw a graphic based on a data table
* As described in the previous use case, this would allow, from a data
cell perspective, to retrieve the associated heading cell content to
associate/create an label to each quarter on the generated pie chart.

An issue with this is about the scope used for the HTMLCollection of
the headerCells property. I means is that would return headerCells for
a row perspective, for a column perspective, for a row group
perspective, for a column group perspective or all of them.

> >  - each cell element could have "rows" and "columns" properties which
> > would be the HTML collection of each rows and columns covered by their
> > rowspan and colspan attributes

Use case: Draw a pie chart based on a sub-set of data contained in a
data table and retrieve heading cell content associated to the data
cells.

This would be preferable to be used instead of having the "cells"
property on "th" and the "headerCells" property on "td".

The "rows" and "columns" HTMLCollection can contains reference of all
"tr" and "col" of the cells covered by it's rowspan and colspan
attribute.
However, it is possible to retrieves the cells, with current API, from
a row perspective "tr"  but not from column perspective "col". A
suggestion would to add a "cells" property to the "col" API.

Regarding the grouping issue, the "tr" and "col" API can have both a
property named "groupIndex" where it would be possible to know the
exact scope of the each cells in a row or column perspective.


> > Actually we can use getElementByClassName(), so we often see
> >
> > MySection
> >  > scope="row">MyNameMyData
> > + 
> > MySubNameMySubData
> >
> > instead of
> >
> > MySection
> > MyNameMyData
> > + 
> > MySubNameMySubData

In both, is the second row is data summary of the data contained in
the third row ? A data table like the Nutrition Facts Table ?
(http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-2.html)

> Do you have examples of pages that are like this that would benefit from
> the API you describe?

http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-3.html
http://wet-boew.github.com/wet-boew/demos/tableparser/rowgrouping-techniques.html

Initial design done by content provider to represent complex tabular
data contains sometime row grouping. But when it became to put them in
HTML and because of the complexity of making those complex table
accessible WCAG compliant they are split in several simple table
combined with a set of heading (). The  is use in replacement
of the row group header. That force to repeat the column cells header
on each simple table instead of having a feature that would allow to
froze the column cells header during the scrolling. I would leave that
for later but this is one use case where is valuable to add a "level"
property to "tr", "col", "tbody" and "colgroup" API

Cheers

:-)

Pierre Dubois

Re: [whatwg] Sortable Tables

[Christoph Päper]

Ian Hickson (2012-11-06):
> On Thu, 1 Jul 2010, Christoph Päper wrote:
>> 
>> For starters, only rows inside ‘tbody’s shall be reordered.

That means every row groupp shall be sorted independently from others, while 
‘thead’ and ‘tfoot’ remain unsorted, possibly bearing sort widgets.

>> Not every table has content that makes sense to be sorted in a different 
>> order.
>> So sortable tables should be marked as such.

We shall use opt-in, obviously. It’s not strictly necessary to mark ‘table’ as 
sortable, if at least one of its rows is marked as such, but it would be handy 
for “autosort” where the author just wants to enable sorting without specifying 
the details.

  

(Table collapsing is a slightly different beast, but related. Let’s deal with 
that separately later, though.)

>> Note that ‘col’ and ‘colgroup’ elements are hardly supported.

But they’re essential for assigning sort properties.

  
  

A ‘col’ inherits the ‘key’ from a parent ‘colgroup’, but may override it.

>> Not every column has content that makes sense to be sorted in a different 
>> order. So non-sortable columns inside sortable tables should be marked as 
>> such.

Here, I’m talking about columns that should be sorted, but not act as sort 
keys. See below for fixed columns.

  
  

>> There are different ways to sort, eg. numeric, temporal or alphabetic 

This easily gets more complex than you wish.

 = 
  1 = 100% = 1.0 = 1e0 = 2/2 …
 Ä = ä = Ä …
 2012-11-06 = 2012-W45-2 …
1000 g = 1 kg = 0.001 t > 1 lb

can of worms
hardly better

The default ‘key’ is ‘auto’ for explicit columns and ‘none’ for implicit 
columns. 

>> and ascending or descending.

It’s probably overkill to give authors the means to specify the preferred 
direction. It’s certainly not sane to let them exclude one or the other.

>> Therefore columns should bear (…) what kind of content their cells have.

Authors will mess this up of course, but then it’s their fault. Let’s not 
overload ‘title’ or ‘abbr’.

>> Several columns may be used for sorting by some kind of priority.

This is a UI question, though.

>> The original order must be restorable.

Also mostly a UI issue, although if authors could describe how they initially 
sorted the data, that could also be used. They would err and lie more often 
than not, though.

>> Cell content may not consist of the string that should be used verbatim (…).
>> Cells should have an optional attribute indicating their sort key.

  The Rolling Stones
  1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

  

> This is a very interesting idea.

It was in 2010 and still is.

Pitfall: ‘rowspan’ and ‘colspan’

Cells may span several rows or columns or both, and are always rectangular. 
Therefore, we should not sort cells! We should sort slots instead, as defined 
in 
.

A slot is uniquely identified by its row and column numbers and itself is not 
represented in markup, i.e. in CSS, it cannot be selected by element or other 
generic selectors, but a pseudo-element like ‘::slot(row,column)’ would be 
possible, and is as desirable as something like ‘getSlotValue(x,y)’, possibly 
cf. . 

Assuming current attributes and elements, a ‘td’ or ‘th’ cell covers 
‘rowspan’בcolspan’ slots and each of these has the same value. The slot value 
is that of its cell, and dynamically changes with it. The cell value is either 
its content normalized to a string or, if present, the value of its ‘value’ 
attribute. Sorting is done by first evaluating the slot values as suggested by 
the ‘key’ attribute value valid for their column, and by second sorting rows 
using the slot values in the user selected (or default first) column as primary 
key accordingly. If the same column has been used for the previous sort, the 
order is reversed (ascending ↔ descending). If a different column has been used 
before, it’s used as secondary key, and so on.

Cells spanning several columns (only) will usually remain intact for normal, 
vertical sorting, unless an affected sort key is set to ‘fixed’ in exceptional 
cases. Cells spanning multiple rows in the column to be sorted by, usually 
remain intact, too. Other cells spanning multiple rows (and possibly columns) 
need to be split into slots for sorting and (optionally) should be rejoined as 
far as possible afterwards.

To support this, cells must be splittable!

  td {color: green;}
  #split {color: red;}

  3  red
  1
  2  green

after sorting by the first column should look like

  1  red
  2  green
  3  red

would if duplicate IDs were legal. The DOM tree, however, would not change! The 
value of the cell at position (1,1), i.e. second row and column since we count 
from zero, is always undefined, but the value of the slot at (1,1) changes from 
“red” to “green”.

Once we have splittable 

Re: [whatwg] Sortable Tables

[Silvia Pfeiffer]

On Wed, Nov 7, 2012 at 6:55 AM, Boris Zbarsky  wrote:

> On 11/6/12 11:39 AM, Ojan Vafai wrote:
>
>> This is a use-case that I absolutely think it makes sense to address.
>>
>
> Agreed.  Not that I can commit to implementing, necessarily, but I do
> think this is a common want.
>
>
Great to hear browser interest! It's something I've had to implement for
basically all Web apps I've been involved with developing, so am really
keen to get browsers to take this over.

Not quite new, but a good requirements analysis can be had from the list of
JS solutions here:
http://tympanus.net/codrops/2009/10/03/33-javascript-solutions-for-sorting-tables/

I our apps, we'd typically not associate sortable to the table, but to a
column header.
Typical classes/attributes we'd add to a table header cell:
* sortable class: boolean
* data-direction: ascending/descending
* data-type: date, number, text etc which determines the comparison
function used in sort
* data-sort-prio: numeric indicating sorting priority

Also, a sortable table's header needed some indication of the sortability,
so some default CSS like this:
th.sortable {
  &:after { content: " ▲▼"}
  &.current{
&[data-direction="asc"]:after { content: " ▼"}
&[data-direction="desc"]:after { content: " ▲"}
  }
}

HTH...

Cheers,
Silvia.

Re: [whatwg] Sortable Tables

[Boris Zbarsky]

On 11/6/12 11:39 AM, Ojan Vafai wrote:

This is a use-case that I absolutely think it makes sense to address.


Agreed.  Not that I can commit to implementing, necessarily, but I do 
think this is a common want.



A couple thoughts off the top of my head:
1. Would sorting actually reorder the DOM nodes or just change their visual
order? It's not clear to me which one is better. I think the former is what
you'd want most of the time.


The former also makes defining the interaction of dynamic mutations with 
sorting much much simpler


Another obvious question: how does (or should) sorting interact with 
rowspans?


-Boris

Re: [whatwg] Sortable Tables

[Ojan Vafai]

On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson  wrote:

> On Thu, 1 Jul 2010, Christoph Päper wrote:
> >
> > It's a common task outside HTML to sort tables by one or more of its
> > columns.
> >
> > There does seem interest among web content providers in making tables
> > client-side sortable since there are several Javascript solutions to do
> > just that, eg. ,
> > . From these we can learn what would be
> > needed from markup to help sorting algorithms. None of this must be
> > behaviorial, but descriptionary.
> >
> > For starters, only rows inside ‘tbody’s shall be reordered. For now
> > columns don’t have to be reordered, ie. only vertical, no horizontal
> > sorting. Nevertheless the design should make it possible to add the
> > other direction later.
> >
> > Not every table has content that makes sense to be sorted in a different
> > order. So sortable tables should be marked as such. Note that ‘col’ and
> > ‘colgroup’ elements are hardly supported.
> >
> > Not every column has content that makes sense to be sorted in a
> > different order. So non-sortable columns inside sortable tables should
> > be marked as such.
> >
> > There are different ways to sort, eg. numeric, temporal or alphabetic
> > and ascending or descending. Therefore columns should bear information
> > how they should be sorted, ie. what kind of content their cells have.
> >
> > Several columns may be used for sorting by some kind of priority.
> >
> > The original order must be restorable.
> >
> > Cell content may not consist of the string that should be used verbatim
> > for sorting purposes, eg. leading articles or similar numbers with
> > different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional
> > attribute indicating their sort key. The ‘time’ element already provides
> > the necessary metadata features for temporal sorting – maybe there
> > should be more of such elements instead.
> >
> > There may be columns that shall remain stable, eg. rank numbers.
>
> This is a very interesting idea.
>
> Is this something browser vendors would be interested in implementing? I'm
> hesitant to add a feature for this (which could be somewhat involved)
> before having the definite interest of some browser implementors.


This is a use-case that I absolutely think it makes sense to address. This
is extremely common whenever people use tables for actual tabular data and
it's non-trivial to do in a way that performs well. I'd have to see a more
concrete proposal in order to evaluate whether I'd be interested in
implementing it.

A couple thoughts off the top of my head:
1. Would sorting actually reorder the DOM nodes or just change their visual
order? It's not clear to me which one is better. I think the former is what
you'd want most of the time.
2. What values should the sort property allow. One idea is that it takes a
JS function similar to what JavaScript's sort function takes. If you leave
it out then it just does alphanumeric sort.
3. What elements does it go on? I don't see what it would do on a td. I
could see putting it on a th though. Also, it's not clear to me what would
get sorted. For example, in some tables, you would group trs inside tbodys
and want to sort those.

Re: [whatwg] Sortable Tables

[Ian Hickson]

On Thu, 1 Jul 2010, Christoph Päper wrote:
>
> It's a common task outside HTML to sort tables by one or more of its 
> columns.
> 
> There does seem interest among web content providers in making tables 
> client-side sortable since there are several Javascript solutions to do 
> just that, eg. , 
> . From these we can learn what would be 
> needed from markup to help sorting algorithms. None of this must be 
> behaviorial, but descriptionary.
> 
> For starters, only rows inside ‘tbody’s shall be reordered. For now 
> columns don’t have to be reordered, ie. only vertical, no horizontal 
> sorting. Nevertheless the design should make it possible to add the 
> other direction later.
> 
> Not every table has content that makes sense to be sorted in a different 
> order. So sortable tables should be marked as such. Note that ‘col’ and 
> ‘colgroup’ elements are hardly supported.
> 
> Not every column has content that makes sense to be sorted in a 
> different order. So non-sortable columns inside sortable tables should 
> be marked as such.
> 
> There are different ways to sort, eg. numeric, temporal or alphabetic 
> and ascending or descending. Therefore columns should bear information 
> how they should be sorted, ie. what kind of content their cells have.
> 
> Several columns may be used for sorting by some kind of priority.
> 
> The original order must be restorable.
> 
> Cell content may not consist of the string that should be used verbatim 
> for sorting purposes, eg. leading articles or similar numbers with 
> different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional 
> attribute indicating their sort key. The ‘time’ element already provides 
> the necessary metadata features for temporal sorting – maybe there 
> should be more of such elements instead.
>
> There may be columns that shall remain stable, eg. rank numbers.

This is a very interesting idea.

Is this something browser vendors would be interested in implementing? I'm 
hesitant to add a feature for this (which could be somewhat involved) 
before having the definite interest of some browser implementors.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposals for better support of Tables

[Ian Hickson]

On Mon, 7 Feb 2011, Alexandre Morgaut wrote:
> 
> The HTML Table API provides powerful attributes like:
> - "scope"
> - "headers"
> - "colspan"
> - "rowspan"
> 
> All of them give informations about relationships between the table 
> cells, rows, and columns
> 
> It would be very helpful if:
>  - each "th" element could have a "cells" property which would be the 
> HTML Collection of each "td" they are heading
>  - each "td" element could have a "headerCells" property which would be 
> the HTML Collection of each of their related "th"
>  - each cell element could have "rows" and "columns" properties which 
> would be the HTML collection of each rows and columns covered by their 
> rowspan and colspan attributes

I was looking at this, and I think such an API is very attractive from a 
theoretical perspective, but I don't really understand what problem it 
would solve. Can you elaborate on what use cases you have for this? What 
would the page be doing with this API?


> Actually we can use getElementByClassName(), so we often see
> 
> MySection
>  scope="row">MyNameMyData
> + 
> MySubNameMySubData
>   
> instead of
> 
> MySection
> MyNameMyData
> + 
> MySubNameMySubData

Do you have examples of pages that are like this that would benefit from 
the API you describe?


> About "headers" I wonder if this would be acceptable:
> 
> MySection
> MyNameMyData
> + 
> MySubNameMySubData
> 
> as for the third row, the th1 header is implicit from the th2 declared header

Yup, that is allowed and is defined to work as you'd expect.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] SecurityError with parent, top, window, self and opener members of Window

[Andrew Oakley]

The specification seems to indicate that a SecurityError exception
should be thrown when the parent, top, window, self and opener
properties of a Window object are access by scripts with a different
effective script origin.  Some testing in Chrome, Firefox, IE and Opera
indicates that this is not what the browsers actually do.

I can't see any reason why we can't allow access to these properties,
should they be in the list of exceptions in section 6.2.1?  Are there
any more properties that should be in the list?

-- 
Andrew Oakley