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

I am not sure why there is a need to "disable" a table cell?

If we take the common presentation of the "Periodic table" as an example of a table that requires "disabled cells" then:

If the table is presented in HTML only it may look ugly but can easily be understood by the user.
If we use CSS and JavaScript we can create a beautiful periodic table stripping all backgrounds and borders and then adding them only where content exists and using the correct colours through conditional formatting adding cascading classes on demand. How would "hiding" <td> in HTML affect scripts that count cells e.g. colour every 4th cell blue?

The "Periodic table" is of course static but taking that model forward to dynamic tables surely the table is best kept as a simple grid e.g. x rows by x columns keeping all visual formatting in CSS?

Lastly in terms of browser compliance I seem to remember Netscape not colouring the backgrounds empty table cells. With the choice of browsers growing would it not increase the risk disparity?

Regards,
Dean


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: 23 March 2010 20:26
To: Leif Halvard Silli
Cc: HTMLwg
Subject: Re: HTML's table model vs @hidden & display:none

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

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

~TJ

Received on Wednesday, 24 March 2010 08:42:19 UTC