Likewise, this one has been cleared up in the latest CSS 2.1 Candidate 
Recommendation [1]:
    “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 
this.

Vincent

[1] http://www.w3.org/TR/CSS21/tables.html#collapsing-borders

Vincent Hennebert wrote:
> Hi,
> 
> 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:
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200505.mbox/[EMAIL
>  PROTECTED]
> 
> 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?
> 
> Thanks,
> Vincent

-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to