W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2007

Border- and padding-conditionality and fences

From: Vincent Hennebert <vincent.hennebert@anyware-tech.com>
Date: Wed, 04 Apr 2007 21:10:11 +0200
Message-ID: <4613F813.2020003@anyware-tech.com>
To: xsl-editors@w3.org
CC: fop-dev@xmlgraphics.apache.org
Dear XSL Editors,

I have another question regarding border- and padding-conditionality.
Please see the attached fo file, which gives a two-page document: the
question is whether the padding-before of the inner block should be
discarded or not on the second page.

The intuitive answer would be yes (at least I think this is what most
users would expect).

However, if we strictly follow the rules of the XSL-FO 1.1
Recommendation it seems that the padding should actually be retained.
Indeed it would be discarded if the before-edge of the area generated by
the inner block were a leading edge in the normal-flow-reference-area
(of the second page, let's call it R). This is explained in the last two
paragraphs of section 4.3.1, "Space-resolution Rules" of the XSL-FO 1.1

This edge would be a leading edge if the inner blocks's area would begin
the normal-flow-reference-area (section 4.2.5), that is if it had
a stacking constraint with R and if none of its ancestor areas had
a non-null space-before.

However, the retained border on the outer block creates a fence before
the area generated by that block; which prevents the inner area from
having a stacking constraint with R. Thus the edge is not a leading edge
and the padding-before should be retained.

What is interesting is that if the outer block had a discarded
border-before then the padding would also be discarded, as this time
there would be a stacking constraint between the inner area and R.

Also, if the outer block were instead a block-container, then the
padding would again be discarded, because the reference-area to be
considered would be the one generated by the block-container.

One developer came up with an interesting interpretation: the rules at
the end of section 4.3.1 should be taken only to determine if border and
padding create fences preventing stacking constraints to occur (as seems
to be implied by the "for purposes of the stacking constraint
definitions" sentence). And that the notion of leading/trailing /area/
should instead be considered to determine if borders and padding should
actually be discarded or not.

While this interpretation makes sense and would match users'
expectations, I'm not sure if it is really intended by the
Recommendation. So could you please provide a clarification on this

Vincent Hennebert

Received on Wednesday, 4 April 2007 19:11:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:24 UTC