Re: HTML's table model vs @hidden & display:none

Tab Atkins Jr., Tue, 23 Mar 2010 10:50:19 -0700:
> On Mon, Mar 22, 2010 at 9:23 PM, Leif Halvard Silli wrote:
>> http://dev.w3.org/html5/spec/tabular-data.html#table-model

>> 
>> I cannot see that it is said that CSS (e.g. td{display:none}) affects
>> the table model.
> 
> This is implicit in the fact that the <td> no longer has display:table-cell.
> 
>> And I suspect that the @hidden attribute also has the
>> same effect.
> 
> Actually, I'd prefer if <td hidden> acted like it was
> visibility:hidden.  The cell is currently irrelevant, but is still a
> cell in the table.
> 
> Ian, any chance we could get this in the default UA stylesheet?

If you suggest that it should act like visibility:hidden, then I 
suggest we should have @disabled attribute for <td> and <th>, which 
should more or less have the effect of setting it to display:none.
 
>> But there is nothing said about that either. I suggest
>> changing the spec to say that CSS td{display:none} or - better - <td
>> hidden > (or some equivalent attribute aimed at this particular
>> purpose) takes part in the table model.
>> 
>> Problem: The HTML table model has a problem with its logics. Good news:
>> the logical problem seems to be solvable via either CSS and/or the
>> @hidden attribute.
>> 
>> Example of the problems: This CSS selector,
>> 
>>        td:first-child+td {background:red}
>> 
>> will in the following table,
>> 
>>  <table>
>>  <tr id="row1"><td            >1<td>2<td>3</tr>
>>  <tr id="row2"><td colspan="2">1<td     >3</tr></table>
>> 
>> select different columns in each row. (Second column in #row1, and
>> third column in #row2.) This may or may not be what the author wants.
>> But at any rate, it often comes as a surprise. ;-)
> 
> Indeed, but that's not a problem with the table model, it's a problem
> with the interaction between the table model and the operation of
> Selectors.  Selectors are tree-agnostic; you just hand it some type of
> document tree, and it goes to town.  Tables are *not* trees, though we
> represent them as such in HTML because it's just easier, and generally
> the mismatch isn't significant.

(Just "for reference", if not trees, then what are they? Grids?)

Please note that I described *two* problems: CSS and (hand) authoring. 
The solution I suggested is simpler, when one is (hand) authoring, 
because it allows the author to see the structure, even if the cell is 
disable.

> The correct way to select cells in a column, paying attention to
> row/colspans, is to use a CSS pseudoclass that can pay attention to
> the special rules of tables, rather than just the structure of the
> tree.  We discussed this some time ago on the www-style list, and the
> solution is very simple.  We will add, either in the current Table
> Layout module or in the next version of it, a :col() pseudoclass
> (takes a selector, and matches any cells which correspond to the <col>
> matched by the selector) and a :nth-col() pseudoclass (takes a number
> or numerical expression, and matches any cells in the columns
> corresponds to those numbers).
>
> For your particular case, where you wanted to select the cells in the
> second column, you'd just do "td:nth-col(2)".

OK. So it is just to sit down and wait until, 10 years from now, all 
significant user agents have catched up.

The :nth-col() solution seems fine. And it is the more fine because it 
is not incompatible solution I suggest - which is a solution that works 
*today*. (Give and take the usual IE peculiarities and stuff, which we 
know how to work around.)

>  No need to do hacky
> tricks in your markup with adding phantom cells to your HTML to allow
> more predictable CSS.

Since you claim "hack", what is the problem with the solution I 
suggest? I have tested, and it works in XHTML and text/html. Across 
browsers.
-- 
leif halvard silli

Received on Tuesday, 23 March 2010 18:23:47 UTC