- From: Dean Leigh <dean.leigh@deanleigh.co.uk>
- Date: Wed, 24 Mar 2010 08:41:18 -0000
- To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "'HTMLwg'" <public-html@w3.org>
I am not sure why there is a need to "disable" a table cell? If we take the common presentation of the "Periodic table" as an example of a table that requires "disabled cells" then: If the table is presented in HTML only it may look ugly but can easily be understood by the user. If we use CSS and JavaScript we can create a beautiful periodic table stripping all backgrounds and borders and then adding them only where content exists and using the correct colours through conditional formatting adding cascading classes on demand. How would "hiding" <td> in HTML affect scripts that count cells e.g. colour every 4th cell blue? The "Periodic table" is of course static but taking that model forward to dynamic tables surely the table is best kept as a simple grid e.g. x rows by x columns keeping all visual formatting in CSS? Lastly in terms of browser compliance I seem to remember Netscape not colouring the backgrounds empty table cells. With the choice of browsers growing would it not increase the risk disparity? Regards, Dean -----Original Message----- From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Tab Atkins Jr. Sent: 23 March 2010 20:26 To: Leif Halvard Silli Cc: HTMLwg Subject: Re: HTML's table model vs @hidden & display:none On Tue, Mar 23, 2010 at 11:23 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 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. > (Just "for reference", if not trees, then what are they? Grids?) Yes, precisely. A table is a grid, with each cell having two "parents", a <tr> and a <col>. That can't be fully expressed in the tree-based model that the DOM uses. > 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. > OK. So it is just to sit down and wait until, 10 years from now, all > significant user agents have catched up. That's how progress on the web works, unfortunately. > 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. 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. >> 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. 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. ~TJ
Received on Wednesday, 24 March 2010 08:42:19 UTC