[webkit-dev] HTML4 and CSS2 table column styling

[Rob Burns]

I started to post a reaply on this bug on HTML/CSS column issues,  
when it grew to more listserv length post. So here it is.

I'm not totally clear why these table column issues are plaguing so  
many browsers. I'm not yet that familiar with the WebKit codebase,  
but the problems with implementing this do not seem that severe. This  
is one area where IE has been able to get the upper hand (from what I  
understand). It’s seems a bit confused too. The HTML4 recommendation  
already begins to talk about these presentation properties (align,  
width, etc.) being taken over by CSS. However, CSS seems to drop the  
ball (by deprecating the <string> value for text-align for example).  
Ideally, I think these features should be implemented through CSS.  
Once WebKit was capable of presenting tables in flexible ways, I  
imagine the HTML4 attribute behaviors could be implemented through  
CSS. The only thing that I think pure CSS 2 could not handle, would  
be extracting the character value from the 'char' attribute for use  
as the <string> value in text-align. Regardless, implementing a 2D  
table model within (nearly recommendation compliant?) CSS seems  
pretty straight forward to me (though it does require a flexible  
reading of the W3C recommendations). In doing so, WebKit would  
provide features that content-creators want and it would also be  
matching features provided by IE. Much of the barriers and objections  
I hear raised about fixing these table-column issues stem from  
thinking of CSS (which is a presentation layer) as too intricately  
linked to the structural tree layer of a document.

Having said that, I think a complete implementation of table columns  
requires more than just a consideration of inheritance. There are  
three separate issues involved with table columns:

Properties of boxes displayed as table-column and table-column-group  
(these are explicitly discussed in CSS recommendation):
border
background
width
visibility
computed values (both HTML attributes and CSS properties) which are  
inherited by table-cells from table-columns or table-column-groups
Properties applied through contextual selectors descending from boxes  
displayed as table-column and table-column-group (e.g.,  
col#mySpecialColumn > td {color: blue;} )

We need to think in two dimensions (i.e., a table-cell has two  
parents) All that's needed is to think of:

table-cell boxes as descendants of both table-row and table-column boxes
those "table-grid" (column and row) boxes can descend from their  
corresponding table-row-group or table-column-group boxes
finally, those "table-grid-group" boxes descend from a common table  
or inline-table box
All that's needed is to rank the precedence of the two parent  
elements, whether considering inheritance on one hand and the  
specificity of descendant selectors following the column or row path  
on the other hand.

Elaborating on the proposed W3C CSS2.1 recommendation for determining  
specificity:

count 1 if the declaration is from a 'style' attribute rather than a  
rule with a selector, 0 otherwise (= a) (In HTML, values of an  
element's "style" attribute are style sheet rules. These rules have  
no selectors, so a=1, b=0, c=0, and d=0.)
count the number of ID attributes in the selector (= b)
count the number of other attributes and pseudo-classes in the  
selector (= c)
count the number of element names and pseudo-elements in the selector  
(= d)
count 0 if the rule’s owner declaration’s selector involves a  
selector for a box with display table-column or table-column-group  
(i.e., it descends from a column). 1 otherwise.
However, when considering certain properties, then reverse this: 1 if  
the selector involves a table-column or table-column-group, 0  
otherwise. (= e). The reversed properties could be up for debate. Or  
they could be listed in another property (e.g.: "column-priority- 
properties: text-align, font-family, font-size;"). Or this reversal  
could just be skipped. However, I 'm thinking of the reversals made  
in HTML4 with align (horizontal).
[…]

Concatenating the fourfive numbers a-b-c-d-e (in a number system with  
a large base) gives the specificity.

This means that within the associated stylesheets, any 'display'  
property rules taking a value of 'table-column' or 'table-column- 
group' or 'table-cell" must be processed (cascaded) before any other  
rules. Otherwise this alternate specificity calculation cannot be  
performed. Once that has taken place it shouldn't require any  
additional ivars (as far as I can tell): just a more elaborate  
conditional statement.

Just as in the case of contextual selectors, a parallel issue arises  
for inheritance. The inherited value for a table-cell could come from  
either a table-row (and its group parent or the table itself) or a  
table-column (and ultimately its group-column or group-row parent or  
the table itself). However, the only extra conditional processing is  
in considering inheritance from two parents rather than one.

Again, changing the recommendation inheritance passage slightly:

If the cascade results in a value, use it.
Otherwise, if the property is inherited and the element is not the  
root of the document tree, use the computed value of the parent  
element., except if it is display-table-cell. In that case check the  
table-cell box’s parents to see if those have a cascade value other  
than inherit. If so, apply this cascade value to the table-cell in  
the following order of precedence: A) the table-row parent; B) the  
table-column parent.
Otherwise use the property's initial value. The initial value of each  
property is indicated in the property's definition.
This means that instead of checking one parent, WebKit checks two  
parents. Beyond those parent boxes, this quickly converges back to  
the same ancestor table box whether through the column path or the  
row path. This also degrades gracefully to the W3C specification.  
Only content creators setting properties on columns or column-groups  
will notice any difference (which means they're likely looking for  
this difference). Again, the algorithm could be made a bit more  
intricate by swapping the priority between row and column as the  
HTML4 spec does with cell align (horizontal) and valign. It may also  
require an extra bool on table-row, table-column, table-row-group and  
table-column-group boxes to indicate when their property (or perhaps  
attribute) values are from a cascade.

This is a generalized solution that would probably be a W3C  
recommendation if the relevant WG believed it could work. IE has  
shown that much of this this can be done already. If WebKit shows how  
its done, Mozilla and Opera could probably be convinced to follow.  
Then the CSS3 Table module recommendation could make it law.

Again, I'm not yet familiar enough with the WebKit codebase to know  
if there are practical implementation barriers to this approach.  
Please reply if you know of any issues that could arise.

If this was done well enough, imagine this 2D Table Style Challenge  
(to follow on the heels of the Acid2 challenge): display a transposed  
table through CSS.

table {display: table;}
caption {display: table-caption;}
td, th {display: table-cell;}

tr {display: table-column;}
tbody {display: table-column-group}
col {display: table-row;}
colgroup {display: table-row-group;}

Now that would be separating semantics from presentation!

I welcome any suggestions anyone has on this. I may use this project  
as an exercise to familiarize myself with the code. Most of WebKit's  
table bugs are minor, but I think the one's surrounding column  
styling are relatively fundamental.

Best wishes,

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070302/2a8c207a/attachment.html