Re: text-align property for columns (once again)

2009/4/9 Reg Me Please <regmeplease@gmail.com>:
> On Thu, 2009-04-09 at 08:14 -0700, Brad Kemper wrote:
>> CSS goes further, and splits markup language (such as (X)HTML) away
>> from appearance/style. And it does so with the assumption of a parent/
>> descendent structure to the markup language. The COL element predates
>> CSS, was created mostly for styling inside the markup language (where
>> it no longer belongs), and is really an oddball in the way it pretends
>> to be a father to the TD, when really the TD only has a mother (the
>> TR). I can really think of nothing else in HTML that is similar. It
>> should really be deprecated, IMO.
>
> Well, maybe there's nothing similar in HTML as there's actually nothing
> similar.
> Tables are 2D structures within a 1D tag stream.
> I'd say this is enough to make them unique.

It is not a 1D tag stream, but rather a tree. Elements have children
and parents regardless of being cells, paragraphs, titles, or
arbitrary XML elements (and regardless of CSS)

> I would not deprecate <col>.
> How would you define "column properties" in a table?
> Cell by cell?

Yes, cell by cell, in the sense that evey cell gets its own
declaration with the property you want (text-align, color, padding,
border-image...).
I don't mean that you must put an ID or a class on every cell of the
column: they way you bind declarations to elements is something that
belong to Selectors. With :col(2), every table-cell that is recognized
as being the second cell in the row (thus in the second column) gets
the property values.

>
>> Are you suggesting that the people on this list are not interested in
>> extending CSS with new features and properties to make it more useful?
>
> Not at all!
> I'm just suggesting to make CSS more powerful and useful.

Ok, the problem is how.

>> COL's lack of parent/descendent relationship to the TD or TH throws
>> normal CSS property inheritance (which is a very key feature of CSS),
>> right out the window. To add it back—in a way that allowed a table
>> cell to inherit from the table column—would be very complicated,
>> requiring a lot more time and effort than you would probably guess.
>
> CSS can be extended this way: columns CAN BE parents of cells (just like
> rows are), despite their position in the syntax tag flow.
> I think that once you accept this concept, everything can fit.

No, you cannot, for two reasons:
1) The DOM tree (or Infoset tree) exists regardless of CSS
2) Even if you build another graph at the CSS level, a graph where a
node has two parents cannot be a tree (because you can have a cycle)
CSS expects that its internal data model is a tree, you cannot change that.

>> And for anything that gets added to CSS, its usefulness must be
>> balanced against the effort required. You have not shown a use case
>> for doing so that could not be handled just as well (or better) by the
>> ":nth-col()" or ":col()" pseudo-classes that we have been discussing.
>> These new pseudo-classes for selecting a table cell based on its
>> column number would allow styling beyond what is available in COL, and
>> would be much easier to implement.
>
> That's interesting indeed. But IMHO it's also duplicating the <col>
> concept that's already in place.

I think that display:table-column is for backward-compatibility
(because, as said, it hurts a lot of core CSS), because HTML existed
before CSS2. The direction is not extending <col>, since that is not
feasible.

> I appreciate a lot the job of the CSS GW and am far from criticizing it.
>
>
>

Giovanni

Received on Thursday, 9 April 2009 15:58:46 UTC