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

If the cells of the periodic table contains @colspan and @rowspan, then 
the feature I ask for could  be useful. But perhaps "disabled" is a bad 
name. Another name could be <td placeholder >  A placeholder cell 
allows me to keep track of the cells both in the code as well as via 
(currently supported) CSS.

The actual periodic table does not seem to need very many cells with 
colspan="*" or rowspan="*". [1] But it could be used in row 1, 2 and 3. 
If the cells in your table contains lots of hard to discern details, 
then it becomes important to keep track of things and know exactly 
where you are in the code.

[1] http://en.wikipedia.org/wiki/Periodic_table

Leif

Dean Leigh, Wed, 24 Mar 2010 08:41:18 -0000:
> 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 21:09:05 UTC