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

On Wed, Mar 24, 2010 at 5:28 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Tab Atkins Jr., Wed, 24 Mar 2010 15:52:06 -0700:
>> On Wed, Mar 24, 2010 at 3:32 PM, Leif Halvard Silli:
>>> 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.

This is not a transition problem.  No user-agent is required to
implement CSS.  Tying HTML semantics to CSS is thus an immediate
failure.

> I guess it is meant that @hidden
> should cause things to be hidden in Lynx as well?

Yes.  Why would you think otherwise?

>>> 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, in a legacy user agent, an author can just supply their own
default styles for @hidden elements.  The fallback isn't *perfect*,
but it's workable.

Note, though, that the author-supplied-styles fallback for @hidden
does *not* screw up table structure for legacy user agents.  They see
the exact same table as a compliant UA.  At worst (legacy, non-CSS
UAs) they'll see the data that you think is irrelevant.  With your
idea, though, they'll see an *entirely screwed up table, with cells in
the wrong column*.

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

That problem has been solved, and will be specced and implemented in
due course.  In the meantime, if you need to select table cells in a
specific column, give them all a particular class.  That's what you
have to do, anyway, if you want to author a page that will display
correctly in UAs that don't support :first-child (legacy IEs, frex).

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

The semantics of @remove, as you have described it, is "This is a
comment."  We already have comments, and they have none of the
problems that I've tried to show you that @remove has.

~TJ

Received on Thursday, 25 March 2010 15:51:50 UTC