- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 6 Apr 2009 12:42:31 -0500
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Reg Me Please <regmeplease@gmail.com>, www-style@w3.org
On Mon, Apr 6, 2009 at 12:27 PM, Brad Kemper <brad.kemper@gmail.com> wrote: > I disagree. Hixie's post describes why properties in general cannot be > inherited from COL. It doesn't really say clearly why those four are > exceptions. And the answer seems to be that they all can be applied > fairly independently of the table-cells: > > The background goes BEHIND the table-cell, so it is only seen if the > table-cell is transparent and no inheritance is involved. > The width only specifies the MINIMUM cell width, but since the table-cell's > width does the same thing, it completely overwrites the width specified in > COL, with no inheritance involved. > Visibility:collapse hides the table-cell, is non-sensical for inheritance, > and other values on visibility there have no effect. > Border is a special case as part of the unique conflict resolution that > substitutes for getting the values from inheritance (with no such > complicated inheritance-free value-passing methods being part of normal > CSS). In theory, I don't see why a similar conflict resolution (namely step > 4) could not be used for 'color' and 'text-align'. Exactly. Those four do not magically apply to the cell at all; they are *legitimately* properties of the column itself, not the table cell. (The closest thing is the border, as you note, but that still doesn't violate anything - during layout, *after* resolution, multiple places are checked to determine table borders. The issue that Hixie cites involves inheritance, which has to be computed *during* resolution. > HTML allows cell alignment to be specified as a COL attribute, so this is > apparently something that goes on anyway outside of CSS-proper and is not > insurmountable to allow special casing of alignment based on the COL's > "style". You've hit the nail on the head. The structure of an HTML table is known after parsing, and doesn't rely on CSS one bit. Thus certain attributes can be applied to <col> elements, and propagated down to the corresponding cells before style resolution happens. The two proposals I mentioned (:nth-col() and :col() pseudoclasses) also work on the HTML table structure, not the CSS table model. Essentially, each <td> or <th> would just remember which column it was associated with, and then the two pseudoclasses would match particular columns based on that. (Interesting aside: the recent talk about adding row-span and col-span to CSS wouldn't affect these pseudoclasses either, for the same reasons, which could result in some strangeness.) Remember, the basic issue revolves around the use of the CSS Table module to determine the column that a cell sits in. If you can figure this out *before* CSS gets brought in, then you're golden. ~TJ
Received on Monday, 6 April 2009 17:43:14 UTC