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

On Tue, Apr 7, 2009 at 12:03 PM, Reg Me Please <regmeplease@gmail.com> wrote:
> This sentence led me to understand that text-align property was
> applicable to table columns.

The @align attribute is valid for <col> elements.  That has nothing
directly to do with the text-align property being applicable to
table-column elements.  One is a statement of HTML, the other is a
statement of CSS.  It turns out that this difference is significant in
this instance.

> Moreover, as text-align can be a property of table rows I have expanded
> the concept to the columns.
> In my superficial knowledge columns and rows are the same thing: ordered
> table cell sets with just different orientation. Which seems to be
> wrong. Rows are cell sets, columns are "something else" with lower
> expressiveness.

It's not that they're 'different', it's that, given the current table
model, table cells are children of table rows.  In HTML, <td> and <th>
are children of <tr>, and the same statement applies in the CSS table
module when talking about elements with table-cell, table-header, and
table-row display values.

Now, conceptually, cells are *also* children of their rows.  But
inheritance throws a wrench into this; which parent gains precedence
if they both have an inheritable property set on them?  The table
model is able to define how this works for a limited number of
properties, but there's no satisfying way to do this in general.
Thus, cells can't generally inherit from both rows and cols, and as
rows are their *actual* parent, that's what was used for normal
inheritance.

That ties into the other reason this doesn't work well - the row of an
element is known at parse time in the CSS module (it's either the
parent element, or an anonymous element placed between the cell and
the parent, and in the latter case inheritable properties are passed
right through from the parent).  The column of an element, however,
isn't known until after everything's been parsed and all CSS values
have been assigned.  At that point it's too late for inheritance to
work normally (because values have already been inherited), and you
can't easily do a general conflict-resolution (for the same reasons I
outlined in the previous paragraph).

> Anyway, some clearer statement in the above mentioned chapter #17.5.4
> would help a lot both users and implementors, in my opinion.

Well, the implementors already know the problems with it, but what
would you like to see for authors?

~TJ

Received on Tuesday, 7 April 2009 18:20:40 UTC