- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 24 Mar 2010 00:38:13 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: HTMLwg <public-html@w3.org>
Tab Atkins Jr., Tue, 23 Mar 2010 13:26:25 -0700: > On Tue, Mar 23, 2010 at 11:23 AM, Leif Halvard Silli wrote: >> If you suggest that it should act like visibility:hidden, then I >> suggest we should have @disabled attribute for <td> and <th>, which >> should more or less have the effect of setting it to display:none. > > That would alter the structure of the table, in what is almost > certainly a nonsensical way. You don't *want* to have table cells > skipping across different columns based on whether an attribute is > present or not. A cell should only be present in the table if it's > *supposed* to be there. .... >> Please note that I described *two* problems: CSS and (hand) authoring. >> The solution I suggested is simpler, when one is (hand) authoring, >> because it allows the author to see the structure, even if the cell is >> disable. > > I'm not sure how <td hidden> is simpler than <!--<td>-->. Same number > of characters, no meaningless cell sitting in the DOM, no twisting of > semantics where you are using a semantic attribute for the sole > purpose of fixing the visual display of the source code. 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. >> 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.) > If we make it *not* do so (that is, if we pretend that <td hidden> or > whatnot is completely ignored by the table model in all ways), then we > get things screwed up when we want use add @hidden to a table cell for > a *legitimate* reason. Our cells, which are set up properly and > aligned with the correct columns, will suddenly shift and match > wrongly. It is not the same whether we use <td hidden> or <td whatnot>. If @whatnot is an attribute with the meaning "disabled cell/element", and if you also apply @hidden to the same cell, what problem would there be? A hidden, disabled cell is extremely redundant. But that's it. Btw: legitimate reason to use <td hidden>? I struggle with that one. If all cells of table has border, and a single one of them has td@hidden, then that cell is not hidden. You will see it. :-) You'll know it is there. When is it useful to set a cell to be hidden, as opposed to have visibility:hidden? And, would @hidden require you to remove all @headers pointing to that cell? Should you also remove the @scope that covers that cell? A table is extremely "tabbed": ]] … must not be used to hide content that could legitimately be shown in another presentation. … incorrect to use hidden to hide panels in a tabbed dialog … Elements that are not hidden should not link to or refer to elements that are hidden. [[ 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 ... But anyway ... I see now that @hidden would not be appropriate. Setting a cell to @hidden would not make it have display:none. So forget about @hidden - that was me not having understood @hidden well enough. >>> 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. Turning display:none into a semantic attribute cannot be more a hack than turning visibility:hidden into a semantic attribute. > To be more specific about problems, aside from the architectural > errors I just pointed out, earlier in this email I pointed out the > problems this would cause when you have a normal, complete table and > then apply @hidden to some of the cells - suddenly cells later in the > table would shift into different columns, both visually and > semantically, completely screwing the table up. It was wrong of me to bring in @hidden. I have not heard that you explained any problems w.r.t. display:none - or a equivalent semantic attribute. Except the problem you mention about the :col() pseudo-class - which is preventable since it is not a standard yet. -- leif halvard silli
Received on Tuesday, 23 March 2010 23:38:50 UTC