- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Sun, 25 May 2003 23:12:03 -0400
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Ian Hickson <ian@hixie.ch>
Ian Hickson wrote: > On Sun, 25 May 2003, Ernest Cline wrote: > > > > I would like to suggest the adding of a new common property value: > > table-inherit that could be applied to any property except display-role > > and display. This exclusion is because the behavior of this property > > value is dependent uppon the value of display-role. > > This would require that the cascade be split into two parts, with the > anonymous table construction in the middle. As I understand it, it is our > intention to move CSS to a world where you can implement the whole > cascade, in one pass, without doing any layout at all. This allows > implementors a much greater freedom to optimise their algorithms and data > structures, something which is important both for small devices, more of > which are implementing CSS every day, and for computers, where users are > clamouring for smaller and smaller layout times. I don't see the problem myself. First of the all, it is quite clear that my proposed value of table-inherit does not apply to low capability devices, since no table support is provided at all in the CSS Mobile Profile, and only basic tables without the COL, COLGROUP, THEAD, TFOOT, or TBODY elements is supported by XHTML Basic. So that leaves only the needs of more capable devices such as PCs to consider. Determiniation of specified and actual values for properties is not affected at all by the addition of table-inherit as I have defined it. The effect of table-inherit occurs at the stage of determining the computed value only. As for the computed values of properties, I have made the following assumptions that should make this not a problem. 1) Which table superiors (table-row, table-(row|head|foot)-group, table- column, table-column-group, and table) a table-cell has is determined by markup. (CSS provides no facility to make the relationship, and relies upon markup to establish the relationships. If CSS is used to give a display-role of table-cell to an element that would normally not have such a display-role then no mechanism exists for these relationships to be determined and therefore a value of table-inherit would have the same effect as inherit. If CSS provided such a facility that would be different, but such a facility in and of itself would complicate rendering far more than the table-inherit value would.) 2) By the time a table-cell is encountered, these table superiors will have at least their start tags encountered. Hence, they will already have had their computed values computed. Hence, all information required to determine the computed value of a table cell that has a specified value of table-inherit is available at the point at which it the computed value of the property would normally be calculated in the absence of the table-inherit value. This is certainly true in the case of both (X)HTML and CALS, which are the only two markup languages with tables that I am familiar with.) If either assumption were not true, so that the computed value of the the elements superior to that cell in the table were not already known at the point where calculating the computed value would be desired then I could see where table-inherit could create problems, as this would require two passes such as you complained about. (Note: As an optimization for the algorithm I gave in my previous post, I also made the assumptions that a table cell would be the descendant of the table it belongs to and that only a table superior that the table cell belongs to would be an intermediate element between the table element and the table cell element. I see now that such an assumption might not apply. Without those assumptions then Step 5 should ignore the computed value of the property when the specified value of the property is inherit for the table and step 6 changed so that the computed value of that property for the table-cell is that which the table-cell would have if the specified value for the property for the table-cell was inherit.) In any case, while I sympathize with the concern for speed, to paraphrase a common saying, a computer program can be made as fast as desired if it doesn't do what is needed of it. I don't see where the addition of table-inherit would be a stumbling block in the quest for speed in currently available CSS and markup languages. In order for (X)HTML tables to be handled so that presentational attributes on COLs and COLGROUPs can be translated into CSS (which I believe is desirable as it would allow for all details of presentation to be handled via CSS instead of the current situation, where correct presentation is dependent upon having an extra non-CSS method of handling some of the presentational attributes), some mechanism for allowing inheritance of values from table-columns and table-column-groups is necessary. Even if this were not something that was desirable, it is still desirable that some method exist for the inheritance of CSS properties from table- columns by table-cells in markup languages which make table-cells children of table-rows. As it is now, in order to apply properties to all cells in a particular column (or column group) requires making each and every cell in that column part of a group despite the fact that it is already known which column that table cell belongs to. This is clearly inefficient.
Received on Sunday, 25 May 2003 23:12:32 UTC