Re: [CSS2.1] col attributes: XHTML and CSS inconsistency?

On Dec 30, 2008, at 7:53 AM, Simetrical wrote:

> On Tue, Dec 30, 2008 at 10:31 AM, Tab Atkins Jr.  
> <jackalmage@gmail.com> wrote:
>> If :nth-col can apply the full range of styling (not just the  
>> standard
>> 4 attributes), then why can't we just move this functionality into
>> <col>?  Does the fact that it's a pseudoclass rather than a normal
>> element allow you to defer the styling decisions somehow?  If it is  
>> at
>> all possible I'd like to avoid introducing a new entity when there  
>> are
>> existing ones begging to be enhanced.
>
> That means that the HTML col element is magical on the CSS syntax
> level.  "foo" in a selector means "match any element named foo", not
> "match any element named foo unless 'foo' is 'col', in which case
> apply special HTML-specific logic".

Yes, agreed. And while the reasons for allowing four properties and  
not others for COL might be historic, there are likely pages out there  
that would be messed up if we suddenly made more properties work in COL.

> However, I don't see why :nth-col() is the most logical substitute for
> HTML col functionality.  It seems like a feature more like the desired
> functionality for col would be :col(), accepting a selector and
> matching any cell that's semantically part of a col element that
> matches the selector.  So for instance, in this table:
>
> <table>
> <col id="col1"> <col id="col2">
> <tr><th id="cell1">Foo <th id="cell2">Bar
> <tr><td id="cell3" colspan="2">Baz
> <tr><td id="cell4">Quuz <td id="cell5">Quuuz
> </table>
>
> ":col(#col1)" would be equivalent to "#cell1, #cell3, #cell4", and
> ":col(#col2)" would be equivalent to "#cell2, #cell3, #cell5".

I guess that would apply to COLGROUPs too?

> This
> is how attributes like align work in HTML4, AFAIK, which is what
> people seem to want.
>
> I assume that would be more difficult to do than :nth-col(), but not
> insurmountable the way markup applied directly to col is.  The
> advantage is, of course, that it would allow things like applying
> rules to columns specified by classes without having to worry about
> what position they're in in the particular table.

The disadvantage of doing it that way is that it requires the HTML to  
have COLs (and/or COLGROUPs) in the table in order to take advantage  
of this. Not only do I hate to add structures to the HTML for purely  
stylistic reasons, but I also often have to style to HTML that I don't  
control. And virtually none of the HTML I ever need to to style  
(including my own) has COL elements. I think the only reason people  
use them is for stylistic reason (whether through CSS or attributes).  
Even char and charoff (used with align="char") should be CSS  
properties, not markup properties. I never use COLs because they are  
so limited in their use that I usually end up needing to rely on TD  
classes instead. I mean honestly, what is the point of being able to  
set the background color and not the foreground color?

I'm just saying. I can see your point about convenience, but being  
able to style nth-col in the absence of any COL tag would be HUGELY  
more broadly useful for the 99% of tables that don't have COL tags.[1]


[1] I made up this statistic. I don't know what the percentage  
actually is.

Received on Tuesday, 30 December 2008 19:52:43 UTC