> -----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. Cheers, Andreas
