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

On Tue, Mar 23, 2010 at 4:38 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

What?  Of course you can be sure about the semantics of <!--<td>-->.
It's a comment.  That's it.  Nothing special required.

The reason you may want to have it is also easy - to make your source
code prettier.  Again, that's it.  Nothing special.

You are trying to fix a perceived problem with source code formatting.
 You brought up a perfectly serviceable solution that doesn't require
any changes to any spec, and has 0 possible side-effects.  What,
exactly, is wrong with just using a comment to indicate the 'missing'
cell?

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

Either @hidden on table-cells is *only* used for this, in which case
we can make :nth-col and all other column-based things ignore the cell
completely, or @hidden on table-cells is useful for other things, in
which case we can't.  We can't do both.  A table-cell is either part
of a column, or it's not.

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

... "whatnot" was used in place of "etc." to indicate that I didn't
care whether the attribute that triggered this alternate behavior was
named "hidden" or something else.

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

Making a table-cell @hidden has the same use-cases as making anything
else @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 ...

In general, @hidden will probably apply display:none rendering.  That
just isn't appropriate for table cells, as it causes the table to
rearrange.

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

What you call the attribute doesn't matter.  You are solving a problem
at the wrong level.

Your problem is that you think that row/colspans sometimes cause
confusing source code.

The solution is *not* to change HTML.  It's to change the way you
format your source code.  Inserting a comment is perfectly sufficient.

> Turning display:none into a semantic attribute cannot
> be more a hack than turning visibility:hidden into a semantic attribute.

@hidden is *not* "turning visibility:hidden into a semantic
attribute", nor is it "turning display:none into a semantic
attribute".  That's nonsensical.  Giving the @hidden element some
particular CSS value is a side-effect of the semantic, not the other
way around.  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.

~TJ

Received on Wednesday, 24 March 2010 17:18:33 UTC