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

On Thu, Apr 9, 2009 at 10:42 AM, Reg Me Please <regmeplease@gmail.com> wrote:
> On Thu, 2009-04-09 at 08:14 -0700, Brad Kemper wrote:
>> 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.

Ah, but it's not that easy!  I've tried to make this clear in my
previous emails.

First, let's assume we're just talking about HTML tables, where all
the relationships can be known to the CSS engine at the beginning.
Now, a cell has *two* parents.  What if both try to set different
values on a property?  Which one wins?  How do you resolve this
conflict?  Current CSS has defined rules for four specific properties,
and then just says that the row always wins for everything else.

Second, let's assume we aren't using actual <table>, <tr>, <col>,
<td>, etc. tags, but rather are using arbitrary HTML/XML elements with
the appropriate table-* display values.  Now we have an even worse
problem.  The CSS engine can't figure out what column a cell is in
until it's resolved all of the display values for all the other
element within the display:table container!  Some of the elements
might be display:table-cell, while others may be display:block and
will get wrapped together into a single anonymous table-cell block.
This can't be determined beforehand.  The problem, though, is that CSS
doesn't resolve rules in multiple steps.  At one point all values are
unresolved, and at the next all values are resolved.  So, by the time
you know what column a cell is in, the cell's value is already fixed
as well!

In fact, the second issue is basically intractable currently.  There
may be a solution later, but CSS currently doesn't have an answer for
it.  You just can't define relationships that rely on such a complex
interplay.

The first issue, though, is easy enough.  Like I said, the row/col
relationships are present in the markup, and so can be figured out by
the parser before the CSS engine even starts.  We just need a way to
declare exactly which 'parent' has precedence.  The :col() and
:nth-col() let us do this - by default, <td>s inherit from their
<tr>s, according to the standard "inherit from your parent" algorithm,
but by saying "td:col(.foo)" we can specify a set of rules that apply
to all cells within the column with class "foo".  Then ordinary CSS
specificity rules can take over to determine which rules win.


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

Indeed, :col() does basically duplicate <col>'s concept, but it does
so in a way that makes much better sense within the CSS model.
:nth-col(), though, does a bit more.  Frex, you can zebra-stripe
columns by using a "td:nth-col(even)" selector.  You can also use
:nth-col() to target columns without having to put a <col> element in
your markup explicitly; "td:nth-col(2)" targets all cells in the
second column automatically.

~TJ

Received on Thursday, 9 April 2009 16:12:44 UTC