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

Tab Atkins Jr., Tue, 23 Mar 2010 13:26:25 -0700:
> On Tue, Mar 23, 2010 at 11:23 AM, Leif Halvard Silli 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.
  ....
>> 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.

This is simple: I cannot be certain about the semantics of <!--<td>-->. 
Whereas I can be certain about the semantics of a <td>. And especially 
about a <td disabled>. This way I can also answer why I *want* to have 
a <td>  - it is sensical. Via CSS selectors, I can also verify that I 
did things correctly.
 
>> 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.

Really? Well, it doesn't have to be defined that way. Not unless there 
other inter-operability problems that are solved by insisting on this 
behavior. If there are such inter-operability problems, then I think 
validators should have much stronger warnings than they I found reason 
to have to date. (To date only Validator.nu warns at all, it seems.)
 
> 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.

It is not the same whether we use <td hidden> or <td whatnot>. If 
@whatnot is an attribute with the meaning "disabled cell/element", and 
if you also apply @hidden to the same cell, what problem would there 
be? A hidden, disabled cell is extremely redundant. But that's it.

Btw: legitimate reason to use <td hidden>? I struggle with that one. If 
all cells of table has border, and a single one of them has td@hidden, 
then that cell is not hidden. You will see it. :-) You'll know it is 
there. When is it useful to set a cell to be hidden, as opposed to have 
visibility:hidden? And, would @hidden require you to remove all 
@headers pointing to that cell? Should you also remove the @scope that 
covers that cell?

A table is extremely "tabbed":

]] … must not be used to hide content that could legitimately be shown 
in another presentation. … incorrect to use hidden to hide panels in a 
tabbed dialog … Elements that are not hidden should not link to or 
refer to elements that are hidden. [[

It is similar with a list item: If it is hidden, the list might appear 
to you as two lists ... Unless it is a numerated list - then a number 
will be failing so you see that is potentially the same list ... 

But anyway ... I see now that @hidden would not be appropriate. Setting 
a cell to @hidden would not make it have display:none. So forget about 
@hidden - that was me not having understood @hidden well enough. 

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

You said about @hidden:

 "I'd prefer if <td hidden> acted like it was visibility:hidden."

I'm OK with that. But I am seeking a @disabled attribute that can make 
a table cell act like it has display:none, *but* with a semantic 
meaning as well. Turning display:none into a semantic attribute cannot 
be more a hack than turning visibility:hidden into a semantic attribute.
 
> 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.

It was wrong of me to bring in @hidden. I have not heard that you 
explained any problems w.r.t. display:none - or a equivalent semantic 
attribute. Except the problem you mention about the :col() pseudo-class 
- which is preventable since it is not a standard yet.
-- 
leif halvard silli

Received on Tuesday, 23 March 2010 23:38:50 UTC