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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
