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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Mar 2010 13:26:25 -0700
Message-ID: <dd0fbad1003231326v1e8bbfefs4baf7280e2fb0783@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: HTMLwg <public-html@w3.org>
On Tue, Mar 23, 2010 at 11:23 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

That would alter the structure of the table, in what is almost
certainly a nonsensical way.  You don't *want* to have table cells
skipping across different columns based on whether an attribute is
present or not.  A cell should only be present in the table if it's
*supposed* to be there.

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

Yes, precisely.  A table is a grid, with each cell having two
"parents", a <tr> and a <col>.  That can't be fully expressed in the
tree-based model that the DOM uses.

> 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.

I'm not sure how <td hidden> is simpler than <!--<td>-->.  Same number
of characters, no meaningless cell sitting in the DOM, no twisting of
semantics where you are using a semantic attribute for the sole
purpose of fixing the visual display of the source code.

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

That's how progress on the web works, unfortunately.

> 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, it definitely *is* incompatible.  The extra <td> will shift the
column that the following <td>s are in, which will affect which cells
get matched by a given :nth-col() rule.

If we make it *not* do so (that is, if we pretend that <td hidden> or
whatnot is completely ignored by the table model in all ways), then we
get things screwed up when we want use add @hidden to a table cell for
a *legitimate* reason.  Our cells, which are set up properly and
aligned with the correct columns, will suddenly shift and match

>>  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.

You are subverting the semantic meaning of an attribute, based on the
visual changes you expect the attribute to apply, in order to fix a
source-code formatting problem.  If that's not a hack I don't know
what is.

To be more specific about problems, aside from the architectural
errors I just pointed out, earlier in this email I pointed out the
problems this would cause when you have a normal, complete table and
then apply @hidden to some of the cells - suddenly cells later in the
table would shift into different columns, both visually and
semantically, completely screwing the table up.

Received on Tuesday, 23 March 2010 20:27:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC