On 23.03.2007 11:49:20 Vincent Hennebert wrote:
<snip/>
> >> How will the red border of the enclosing block be taken
> >> into account in the penalties produced by SpaceResolver on the list of
> >> elements inside the block-container?
> > 
> > Not at all, since they don't interact according to the rules in 4.3.1:
> > http://www.w3.org/TR/xsl11/#area-space
> 
> Well, the width of the border from the outer block must still be
> considered. IIUC the inner block generates pending elements for its
> border-after, which will be converted by SpaceResolver into a Knuth
> penalty at each legal break of the sequence it generates, with a penalty
> length equal to the border width.
> At the outer block level, each penalty from subsequences must be
> modified to also take the border-after of the outer block into account.
> At least that's a way to implement things. Is that actually implemented
> that way?

More or less but not explicitely, rather implicitely. As I said, normal
block-containers are not implemented correctly right now. It doesn't
create a new element list but behaves like a normal block which causes
the fence to be ignored. The result otherwise is often like expected,
even your border is probably handled correctly in many cases. That's
probably the reason nobody has yelled until now. I always knew there was
something not quite right there. The problem is documented here (from 
disabled-testcases.xml):
Auto-height block-containers produce fences 
(block-container_space-before_space-after_3.xml)
    * Block-containers with no height currently don't
          create a fence for spaces as they should (they behave like a
          normal block).

Anyway, I suggest you write a test case for your scenario so we can all
verify that we all have the same expectation and to document a possible
problem with those penalties. Even if only to make sure that this is
handled properly when/after the above bug is fixed and your point may
have been forgotten.


Jeremias Maerki

Reply via email to