This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
6.5.3 fo:block-container states that the inline-progression-dimension of a block container may not be "auto" if the inline-progression-direction is different from that of the parent of the container. Fine, but if a user neglects to specify the inline-progression-dimension on a block container rotated 90 then the initial value of "auto" applies, which I then assume is an error condition. I note that the Antenna House tool treats the dimension as narrow as it can be: as if it were an fo:float in that it is the length of the widest of the children areas. I note that the RenderX tool treats the dimension as wide as it can be: as if it were an fo:block in a parent region area in that it is the width of the parent, not the width of the content. The answer impacts on the position of the next formatting object after the block container: after the narrow container on the same page, or after the wide container on the next page. My intuition is that when not specified the error condition should treat the dimension as a region in which the blocks are placed, that is, the rotated block container is as wide as it can be. This is because while neither fo:float nor fo:block allow inline-progression-dimension to be specified, fo:float explicitly talks about the width of the child areas while fo:block makes assumptions about the width. Can you cite a definitive decision in the specification, or can you explain which of the two interpretations of the recovery from the error condition is "right" (unless, of course, it is just up to the implementation to recover from the error by making its own interpretation). Thanks!
The condition described is an error. In the case of an error, any error recovery is implementation dependent, so the XSL 1.1 Recommendation does not address whether or how to recover. As such, no change to the spec is required. In accordance with the instructions at http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html#verify, please review the proposed resolution carefully, and let the Working Group know whether it's acceptable or not.
Thank you for confirming it is just up to the implementation to recover from the error by making its own interpretation. I figured this was one of the possible outcomes. I appreciate the feedback! . . . . . . . . . . Ken
[marking as "notabug", the best Bugzilla can do in this case! - Liam]