W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: several messages about tables and related subjects

From: Leif Halvard Silli <lhs@malform.no>
Date: Tue, 25 Mar 2008 09:00:08 +0100
Message-ID: <47E8B108.9090700@malform.no>
To: Ian Hickson <ian@hixie.ch>, HTMLWG <public-html@w3.org>

Ian Hickson 08-03-23 20.29:   
> (In HTML5, header cells
> aren't hierarchical. As I mentioned above I studied a large number of
> tables and I couldn't really find a case where there was a real need to
> read the headers' own headers. (In the rare cases where such verbosity is
> indeed desired, the headers="" attribute can be used to point to all the
> headers.)
>    

This leaves us with only "bad practise" use of @headers: When headers="" 
is used on a cell, then it must specify _all_ the headers of that cell.

> >  On the subject of which, does anyone have a strong opinion on how
> >  scope="colgroup" and scope="rowgroup" ought to work? For example, in the
> >  following table, assuming the header is scope="rowgroup", the direction
> >  is ltr, and there is only one rowgroup, which cells should it apply to:
> >
> >  | Cell 1 |  Cell 2  | Cell 3 |
> >  | Cell 4 | Header 1 | Cell 5 |
> >  | Cell 6 |  Cell 7  | Cell 8 |
>
>
> Spec says 5, 7, 8, assuming none have headers="" attributes set.
>    

Thanks for clarifying scope=rowgroup. The above make sense.

> On Fri, 27 Oct 2006, Lachlan Hunt wrote:
> >
> >  All of these attributes should be kept, because they are supported and
> >  non-presentational.
> >
> >  TABLE
> >  * summary (supported by screen readers)
> >
> >  TH and TD
> >  * abbr (I think that's supported by screen readers, but need to verify)
>
> I don't really see that these attributes actually help anyone.
>    

Don't you think that ABBR can be used e.g on small screen rendering? It 
seems like HTML 4 does:

"User agents have two pieces of header information available: the 
contents of the TH element and the value of the abbr attribute. User 
agents must render either the contents of the cell or the value of the 
abbr attribute. For visual media, the latter may be appropriate when 
there is insufficient space to render the full contents of the cell. For 
non-visual media abbr may be used as an abbreviation for table headers 
when these are rendered along with the contents of the cells to which 
they apply."

The above makes me think of "abbr" as a kind of ALT attribute for table 
cells.

The ABBR attribute seems similar to the LABEL attribut of OPTION 
elements. HTML 4:

"label = text [CS] This attribute allows authors to specify a shorter 
label for an option than the content of the OPTION element. When 
specified, user agents should use the value of this attribute rather 
than the content of the OPTION element as the option label."

What does the small screen browser makes say?

I can also think about a general use case: You have made a complicated 
table. You want to offer a simpler access to the same table: Apply ABBR 
attribute to those cells.

What is lacking is a way to specify _when_ ABBR should be preferred. The 
LABEL attribute should be used when it is present. And perhaps it should 
be same rule for ABBR as well.

> On Tue, 5 Feb 2008, Joshue O Connor wrote:
>
>    
> >  To put that comment into context, he is a power user and is experienced
> >  in using his screen reader controls to interrogate data tables.
>
> I would imagine that this would put him amongst those more able to deal
> with summary="" attributes, so that doesn't really help your case. :-)
>    

I would imagine that a power user is one that knows his ways around 
things. One who takes into account typical errors and customs, be they 
good or bad, in order to get done what he wants. A power user might - 
but need not - know how thing _should_ be done. But what he knows best, 
is how things actually and typically _are_ done - and he has adpated 
himself for that.

A poweruser will often be very effective. But not always very efficient. 
Thus, I think that was a valid argument from Joshue.

> >  "Not every column is necessarily in a column group."
> >
> >  Noting that in HTML 4.01 terminology, in the absence of explicit column
> >  groups, there is a single implicit column group.
>
> The only effect here is that scope=colgroup doesn't work in HTML5 without
> a<colgroup>. Bug? Feature?
>    

Visually, the CSS selector colgroup{} does not work when <colgroup> is 
lacking. In that sense, it is probably all right.

And in that context, let's jump to the <TH colspan=0> issue:

> On Sat, 4 Nov 2006, Henri Sivonen wrote:
> > >
> > > None of Opera 9.02, Firefox 2.0, IE7 and Safari 2.0.4 implement
> > > colspan="0" as specified in HTML 4.01. Trident, Presto and WebKit at
> > > least agree on what to do with it: they treat it like colspan="1".
Isn't the real problem here support for COLGROUP?
> > > I suggest that only positive integers be conforming and that
> > > non-conforming values be treated as 1.
> > >
> > > Test case:
> > > http://hsivonen.iki.fi/test/wa10/tables/colspan-0.html
>
> So specified.

And how does that decision relate to the header cell association algorithm?

   For example, say, that in a 3 column <TABLE>, we have one <TR> 
containing only one cell, namely a <TH colspan=0> (or even only a <TH 
colspan=1). Then what about the cells in column 2 and 3 in the following 
<TR>s? Should they not see that <TH colspan=0> as their header cell? 
Example:

<table><tr><th colspan=0>Header for 1,2,3
<tr><td>Col 1<td>Col 2<td>Col 3</table>

   In Firefox, that <th colspan=0> heads the entire table. But even when 
using UAs without support for colspan=0, I believe users will still 
often look at that cell as head for all three columns. Thus it seems to 
me that for the header cell algorithm, it would make sense to think that 
the above <TH colspan=0> equals the entire row.

  And then, if that is so, why not, instead of letting colspan=0 be 
equal to colspan=1, let it cover the entire row, regardless of 
<COLGROUP>. This to let the scope= and the visual rendering be the same.

  The only problem is when there are several cells with colspan=0. 
Firefox currently only works correctly when colspan=0 is equal to the 
entire row. So why not let colspan=0 equal colspan=1 when two or more 
cells with colspan follows in a row?

Actually, based on Henri's test case, it seems like Firefox 3 follows 
that logic now.

Summary: COLSPAN=0 should equal COLSPAN=1, except when it is the last 
cell of the row, then it should fill the rest of the row.
-- 
leif halvard silli
Received on Tuesday, 25 March 2008 08:01:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:53 UTC