- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 27 Mar 2010 17:20:48 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: HTMLwg <public-html@w3.org>
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