Likewise, this one has been cleared up in the latest CSS 2.1 Candidate
“The top border width of the table is computed by examining all
cells who collapse their top borders with the top border of the
table. The top border width of the table is equal to half of the
maximum collapsed top border. The bottom border width is computed by
examining all cells whose bottom borders collapse with the bottom of
the table. The bottom border width is equal to half of the maximum
collapsed bottom border.”
Anyway, all the implementations I tested were behaving similarly on
Vincent Hennebert wrote:
> I’m planning to send a bunch of clarification requests to xsl-editors@
> in the next days. While I’m at it we may also ask for clarification on
> this topic, unless there is something I missed (I must admit that for
> one time every XSL-FO implementation I’ve tried does the same).
> Jeremias already raised the question about that more than 2 years ago,
> which remained unanswered:
> Basically this is not specified (not in XSL nor in CSS2) whether the
> border-before/after should lie half in the margin in the collapsing
> model. At that time it was decided to answer yes, for the sake of
> consistency with border-start/end.
> While this makes perfectly sense, I’m not sure it’s desirable from
> a user POV. After all this will be the only case where
> border-before/after will lie in the margin; for the separate model and
> all other elements (list, block...) this won’t happen. So this is
> consistent in one way, but not on the other.
> That said, this is relatively easy to work around the problem by
> specifying non-null margins (as long as the user isn’t doing exotic
> layouts like in some of the testcases...). And changing the current
> behaviour implies quite a few changes in the code, so I won’t fight for
> this until my last breathe. Just asking for other opinions.
> So, WDYT?
Vincent Hennebert Anyware Technologies
Apache FOP Committer FOP Development/Consulting