Thanks everyone for helping me with this.

On 05.05.2005 20:43:58 Simon Pepping wrote:
> Jeremias,
> 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?

Yes, exactly.

> 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,
>                                                        ^^^^^^^^^^^^^^^^
> > at the cell level."

Yes, but it's the "cell level" part that made think twice. I now
interpret the "each segment" part in the way that each segment has to be
taken to get at the candidates for a non-segmented cell border.

> and
> > "If the value of the border-collapse trait is "collapse", the border for
> > each side of the cell is determined by, for each segment of a border,
>                                           ^^^^^^^^^^^^^^^^
> > selecting, from all border specifications for that segment, the border
> > that has the most "eye catching" border style..."

At the moment I'm not sure what to think. There are parts of this
sentence that let me run on one direction, others let me run in the
opposite direction.

> 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.

Let's hope so.

> 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.

...if the original interpretation was correct.

> 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.

Actually, I think it could but the implications are dreadful. Actually,
so far this is the one reason in all this that urges me to believe that
the original interpretation was indeed correct.

> Note also this remark in the spec (6.7.3 fo:table) about the
> background of spanned cells: "A cell that is spanned may have a
> different background in each of the grid units it occupies." This is
> somewhat similar to the spec allowing different segments on a side of
> a spanned cell.

But that's because you have backgrounds on various levels (rows, columns,
column groups, row groups). If you specify the background on a spanned cell
it fills all the occupying grid units. You have no means to directly specify
a background (at least on cell level) for each of the occupying grid

Again, thanks for helping me here. I guess it's best to just leave it
like it is right now. It's a lot better than nothing even if the
interpretation turns out to be wrong at one point. It also leaves the
whole thing simpler. These are, after all, only nits but with a big
impact on the complexity. And BTW, a XEP trial version matches more or
less my original interpretation even though I found some diffences on
start and end borders.

Jeremias Maerki

Reply via email to