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

Tab Atkins Jr., Wed, 24 Mar 2010 10:17:40 -0700:
> On Tue, Mar 23, 2010 at 4:38 PM, Leif Halvard Silli wrote:
>> 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.
> 
> What?  Of course you can be sure about the semantics of <!--<td>-->.
> It's a comment.  That's it.  Nothing special required.
> 
> The reason you may want to have it is also easy - to make your source
> code prettier.  Again, that's it.  Nothing special.
> 
> You are trying to fix a perceived problem with source code formatting.
>  You brought up a perfectly serviceable solution that doesn't require
> any changes to any spec, and has 0 possible side-effects.  What,
> exactly, is wrong with just using a comment to indicate the 'missing'
> cell?

Is <td style="display:none"> that you describe as servicable? ;-) I 
agree that it doesn't require change to any spec. I took it up partly 
because I was not sure if there are any side effects. 
 
>>>> 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.)
> 
> Either @hidden on table-cells is *only* used for this, in which case
> we can make :nth-col and all other column-based things ignore the cell
> completely, or @hidden on table-cells is useful for other things, in
> which case we can't.  We can't do both.  A table-cell is either part
> of a column, or it's not.

I no longer suggest to use specifically @hidden for this purpose, but 
rather @placeholder or @removed. However, the point of @hidden is to 
hide things without having to physically remove things from a page. A 
physical removal would require changes to the CSS, JavaScript etc for 
that page. The purpose of <td removed > is the same, from the point of 
view of allowing CSS to work as if the cell were not removed. When it 
comes to how :nth-col works, then I don't see why it couldn't be worked 
into its algorithm that it considers e.g. <td removed> as  removed.
 
>>> 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.
> 
> ... "whatnot" was used in place of "etc." to indicate that I didn't
> care whether the attribute that triggered this alternate behavior was
> named "hidden" or something else.

The name is of course not important. Semantics are. I understand that 
the semantic of @hidden is different from the one I am after. Hence I 
suggest another feature.

....
>> 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 ...
> 
> In general, @hidden will probably apply display:none rendering.

That is not what I've heard from Henri.

>  That
> just isn't appropriate for table cells, as it causes the table to
> rearrange.
> 
>>>>>  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.
> 
> What you call the attribute doesn't matter.  You are solving a problem
> at the wrong level.
> 
> Your problem is that you think that row/colspans sometimes cause
> confusing source code.
> 
> The solution is *not* to change HTML.  It's to change the way you
> format your source code.  Inserting a comment is perfectly sufficient.

As I said: I want to catch two flies in the same bang. Comments would 
eventually only catch one of them.

>> Turning display:none into a semantic attribute cannot
>> be more a hack than turning visibility:hidden into a semantic attribute.
> 
> @hidden is *not* "turning visibility:hidden into a semantic
> attribute", nor is it "turning display:none into a semantic
> attribute".  That's nonsensical.  Giving the @hidden element some
> particular CSS value is a side-effect of the semantic, not the other
> way around.

This is a chicken and egg argument.

>  Since an element is @hidden and irrelevant, it shouldn't
> be displayed to visual users, nor read out to speech users, nor
> presented in any other fashion to people using any other presentation
> modalities.  That means that, yes, we apply some sort of appropriate
> CSS to hide it.  But the semantic is separate from the CSS.

Why do you think I suggest to have an attribute solution to a problem 
that I already know that I can solve via CSS?
-- 
leif halvard silli

Received on Wednesday, 24 March 2010 22:33:20 UTC