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

Tab Atkins Jr., Thu, 25 Mar 2010 08:50:57 -0700:
> 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 do not insist on tying it to CSS.

>> I guess it is meant that @hidden
>> should cause things to be hidden in Lynx as well?
> 
> Yes.  Why would you think otherwise?

I did not think it 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.

Right. Of course it would be the same for <td removed >
 
> 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*.

I agree that <td removed> would have that kind of fallback problem.

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

It is only the solution that I suggest that save both things at the 
same time.

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

A comment? It is true that in legacy versions/rendering modes of 
Internet Explorer, then HTML comments are possible to reach via CSS 
selectors. Is that what you mean? ;-)
-- 
leif halvard silli

Received on Saturday, 27 March 2010 16:21:25 UTC