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 Tuesday, 23 March 2010 20:27:18 UTC