> -----Original Message-----
> From: Simon Pepping [mailto:[EMAIL PROTECTED]

Hi Simon,

> At first sight I agree with Andreas' interpretation in his reply to
> this message, which I think is the same as your original
> interpretation. Thinking on, however, I see that there may be a
> problem with spanned cells. Is that what you are aiming at?

Aah, yes! I knew there was something I was overlooking...

> The cell level, means the level of the spanned cell. This suggests
> indeed that each side of a spanned cell must be treated as a whole.
> However, the spec says precisely:
> > "If the value of the "border-collapse" property is "collapse" or
> > "collapse-with-precedence" the border is determined, for each segment,

Indeed, and as you point out below --and I also recall from reading the CSS2
spec-- that segment is actually meant to be the 'intersection between a row
and a column', such that a row- and column-spanning cell can have different
borders and backgrounds for each of the grid-units it occupies.

<snip />
> Moreover, the term 'cell level' is rather vague, and certainly not the
> same as 'per cell'.
> That seems to mean that the determination is done per segment indeed,
> which agrees with your original interpretation. Note that the spec
> does not define the notion of a segment, nor does the CSS2 spec. But I
> take it to mean the side of a grid unit.
> Your Wiki example shows a result that is probably undesirable, a
> spanned cell with vastly different border segments. But apparently the
> spec does not protect the user from specifying such a border
> arrangement.
> Probably it is not possible to define resolution of collapsing border
> specifications per cell. Consider the following example:
>    +--------+----------------+--------+
>    |        |                |        |
>    |        |                |        |
>    |        |                |        |
>    |        |                |        |
>    +--------+-------+--------+--------+
>    |                |                 |
>    |                |                 |
>    |                |                 |
>    |                |                 |
>    +----------------+-----------------+
> On the border between rows 1 and 2 each segment is part of two cell
> borders. Conflicting border specifications can only be resolved per
> segment, not per cell.

Yes and no. Ultimately this problem always poses itself, even in very basic
table-grids, for the first cell's after-border, you might have to wait until
the before-border for the first cell below it is known... (to be able to
fully and correctly resolve the after-borders for the cells in one row, we
need the before-border info for the cells in the next row as well)

The only thing that seems quite impossible (to me, maybe in error) is that
there would be different borders on two sides of the same gridline. In
Jeremias' example this would mean that IF the entire before-border of the
spanning cell has to be the thick red border, THEN this border-style would
also be applicable to the after-border of *both* cells immediately above.
(and suddenly I think I see what Jeremias meant by 'ending up taking the
after-border of the cell to the right...' in his OP)

OTOH, as Jeremias just pointed out in his reply, IF borders are specified at
the cell-level, and the cell spans multiple columns/rows, then that border
would be a candidate for _all_ the relevant segments --not only the first
grid-unit it occupies. If it is dominant over all the others you would end
up with a uniform border on all segments.



Reply via email to