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

On Wed, Mar 24, 2010 at 3:32 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

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

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

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.

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

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

~TJ

Received on Wednesday, 24 March 2010 22:52:59 UTC