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

Tab Atkins Jr., Wed, 24 Mar 2010 15:52:06 -0700:
> On Wed, Mar 24, 2010 at 3:32 PM, Leif Halvard Silli:
>> 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.
> 
> No.  That is attempting to fix a source-code formatting problem with
> CSS, which is equally bad.  Again ignoring the architectural problems
> of this being a solution at *entirely* the wrong level, a user-agent
> that doesn't do CSS will have a screwed-up page.

That would be a transition problem. I guess it is meant that @hidden 
should cause things to be hidden in Lynx as well?
 
>>>>>> 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.
> 
> So now you are trying to invent an entirely new attribute for the sole
> purpose of making your source code prettier?  (Note that, in addition
> to the architectural problems previously mentioned, this also has a
> terrible fallback - in legacy user agents the table will be completely
> screwed up.)

Yes. Fallback problem. But if a legacy UA doesn't support @hidden, then 
the one will have to make sense of things on one's own. Same with 
@removed.

>>>>>>>  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.
> 
> What is the second problem?  As far as I can tell, the only problem
> you've cited is that sometimes row/colspans make the source-code a
> little hard to follow, as you have to mentally insert spanned cells in
> other rows.

The other problem it solves is that <td removed> allows me to use 

 tr *:first-child+*{}

in a predictable way. (Which again allows me to use CSS to check that I 
did things correctly.)

>>>> 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.
> 
> No it is not.  Display flows from semantics.  There are many reasons
> to make things display:none; intending the @hidden semantic is only
> one of them.

*I* started with CSS. But *the semantics* start with the attribute. I 
of course consider that giving <td removed> a particular CSS value is a 
side-effect of the semantic, not the other way around.

>>>  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?
> 
> You can't solve it via CSS.  You can apply a dirty hack that employs
> CSS, but which will have incorrect semantics in all UAs and incorrect
> display in all non-CSS UAs.  That doesn't qualify as a 'solution'.

I agree: @hidden and @remove have semantics. CSS is just the means we 
use to express the semantics.
-- 
leif halvard silli

Received on Thursday, 25 March 2010 00:29:26 UTC