css2 - 17 Tables

A few comments...

...about the SIX-LAYER TABLE MODEL:

The six-layer model is a clever solution, but IMHO it isn't ready for prime
time. From section 17.3[1]: "Note that for a table element, the width
includes the border, and that a table doesn't have a padding. It does have a
margin, however." Contrast that with padding properties[2]: "Applies to: all
elements" and the CSS box model (content and border are _not_ coincident)
and we have contradiction bordering on sacrilege. There's either got to be a
table solution that doesn't blow the integrity of the whole CSS rendering
model.

From section 6.7 of the draft[3]: "CSS introduces the concepts of
pseudo-elements and pseudo-classes to extend the addressing model and permit
formatting based on information that lies outside the document tree." Also:
"Pseudo-elements refer to sub-parts of an element's content..."  Well,
COLGROUP, ROWGROUP, and COL may be part of the document tree, but they're
also sub-parts of a table. Might they not qualify for pseudo-element status?

It seems to me that table formatting would be simplified if cells were
considered to be absolutely positioned -- relative to rows in the vertical
dimension and to columns in the horizontal dimension. The apparent
overlapping horizontal margins on adjacent cells that results from
CELLSPACING could then be explained in terms of positioning rules that don't
conflict with the existing spec. Rather than referring to cell margins, the
HTML CELLSPACING attribute would affect the cells' positioning coordinates.

...about BORDERS:

Overlapping borders for an element and its content don't jive with the rest
of the CSS spec. Why not just specify that a table's HTML BORDER attribute
applies to both the table and its cells? That appears to correspond with the
rendering by some popular UAs. Without CELLSPACING the borders abut and
appear solid. A 3D effect is produced by different colors on top/left and
bottom/right borders.

'Conflict resolution' rules for rendering overlapping borders complicate the
spec for both authors and implementers. Why prevent authors from specifying
unusual border renderings? I believe declared borders should be displayed
without special considerations. For example, I might want light gray rules
to
appear within cells that span multiple rows and columns, such that the
'normal' cell grid is still visible under the cell content. By specifying a
light gray border on rows and columns and a heavier border on table and
cells, I could have this effect, as the borders on the absolutely-positioned
cells would obscure the underlying row and column borders except in those
areas where a cell spans a normal cell division. And if I want to lose the
grid behind certain spanned cells? Easy: just give those cells a background.
And if I want the border of a COLGROUP to appear above the cell borders?
Simple if cells are considered absolutely-positioned: just give the cells a
negative z-index.

ALIGNMENT OF CELL CONTENT (17.6, 17.7)

[Some clarification needed for alignment in spanned cells.]


David Perrell


[1] http://www.w3.org/TR/WD-CSS2/tables.html#h-17.3
[2] http://www.w3.org/TR/WD-CSS2/box.html#h-9.4
[3] http://www.w3.org/TR/WD-CSS2/selector.html#h-6.7

Received on Tuesday, 25 November 1997 17:45:33 UTC