Re: [CSS21] border-collapse with rowspan or colspan

Simon Sapin <simon.sapin@kozea.fr> wrote:

> Le 10/07/2012 17:09, "Gérard Talbot" a écrit :
> > There seems to be a problem with that test. How many columns does (or
> > should) that table have? It seems there is 3 columns (from looking at
2nd
> > row) but the first row uses only 2 columns.
> >
> >> WebKit, Gecko and Opera give three different renderings,
> > If the table is wrongly/imbalancely designed, then different renderings
> > is to be expected.
> 
> I think that the table should have three column with the first row being 
> incomplete. Having incomplete rows is generally not a problem, my point 
> is not there.
> 
> Here is a revised test case:
> http://dabblet.com/gist/3084025
> 
> Remove the D cell. The table is now nicely filled, properly two-column. 
> The initial problem remains: three engines give three different results. 
> I’m interested in the left border of the A cell: what should be drawn 
> and how should the cell’s content be positioned?
> 
> Since A has rowspan=2, the border conflict resolution can give two 
> different results for the top and bottom half of A’s left border.

Yes, that's correct - it does.

Like you, I also spent time implementing the collapsing border model for our
browser but found that I couldn't get any other browsers to agree with the
specification, or at least my interpretation of it.

Cells that span rows or columns are a problem for the CSS specification
because it refuses to deal with it.  The HTML specification doesn't really
deal with it either except saying that it happens.  In my experience, the
only sensible way to implement this is to read the HTML5 specification *but*
substitute anything that talks about elements with the equivalent CSS
terminology where possible.  e.g. when HTML5 says do something with 'tr'
elements, you do it with boxes that are display:table-row.

You have to stop thinking about it in terms of cells and start thinking of
it in terms of edges.  Whatever the content describes, you always end with a
rectangular grid of what HTML5 calls "slots".  Each slot has 4 edges (top,
right, bottom, left) and shares each edge with either another slot or the
table box border.  Whether the slot has a cell (or several if you cause
cells to overlap invalidly!) or not makes no difference: the slot still has
4 edges.

Each edge has 11 potential sources of style: two cells, two rows, two row
groups, two columns, two column groups and the table box.  Anything that
runs along that edge contributes to the border conflict algorithm for that
edge.  So you construct the edge data structure, using the border conflict
resolution rules.  This can all be done in a single pass over all the boxes
in the table, provided you visit them in the correct order (even in the
invalid cases of overlapping cells, this still works, if you're careful)
IMHO, for best results, for cells that span multiple slots, you need to
force all the internal edges to be border-style:hidden (for valid tables,
only a problem for table-column-group and table-column boxes, IIRC)

As you indicate, this gives you a problem with how to assign border widths
to cells.  The solution I chose was to find the maximum width of any edge
along that side of the cell.  This led to the best visual results (you don't
get borders/cell contents on top of each other)  However, this is at odds
with the way that the table box border is specified which says that the
table box border width is determined only by the first row of the table
(Opera uses all rows of the table, as do I, as I prefer that interpretation
to drawing the border into the margins)

Note though, that although the border width needs to be taken into account
in laying out the cell, the border is "owned" by the table box, NOT by the
cell (try absolutely positioning a table cell and you'll see the cell's
background goes to its new position, but its border does not!) - the cell
must simply leave space for it (and draw the cell background into it)
Additionally, even if you do delegate the drawing of the borders to the
individual cells (something I tried!) you come unstuck when it comes to
empty slots in the grid (you can try to fill them with anonymous table cells
so that there's something to draw the border, but that doesn't work either,
again due to positioning)  However, Opera, Firefox and WebKit all muck this
situation up completely in one way or another, too.

Unfortunately, the CSS specification leaves undefined the combined effect of
other critical CSS properties on table-related boxes, too.  I take it you've
not got as far as investigating visibility:collapse and the collapsing
border model?  This causes even more hilarious renderings in different
browsers, but given the lack of any specification is more understandable -
albeit completely bizarre.


> Anyway, I just wanted to make sure that the WG knows that the issue
> exists. The problematic case are IMO not something authors would want to
> do, so I don’t really care if this is fixed.

I care.  Authors do it.  Maybe not the good ones, but there are an awful lot
more of the other type around.



-- 
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited

Received on Tuesday, 10 July 2012 17:01:54 UTC