You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@anyware-tech.com> on 2007/12/13 20:47:06 UTC
Border-before/after half in margin in collapsing model for tables?
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/%3c20050509173251.CF07.DEV.JEREMIAS@greenmail.ch%3e
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
Re: Border-before/after half in margin in collapsing model for tables?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
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/%3c20050509173251.CF07.DEV.JEREMIAS@greenmail.ch%3e
>
> 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
Re: Border-before/after half in margin in collapsing model for tables?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> I see no reason to change anything unless the XSL WG clarifies in one
> direction or the other.
Sure, well, I just wanted to know if there was any indication towards
one or the other behaviour that I may have missed, before sending any
clarification request. But apparently there isn’t (?).
<snip/>
Vincent
--
Vincent Hennebert Anyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting
Re: Border-before/after half in margin in collapsing model for tables?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I see no reason to change anything unless the XSL WG clarifies in one
direction or the other.
On 13.12.2007 20:47:06 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/%3c20050509173251.CF07.DEV.JEREMIAS@greenmail.ch%3e
>
> 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
Jeremias Maerki