On Feb 12, 2007, at 23:34, Jeremias Maerki wrote:
<snip />
I'd very much like to agree with your solution/interpretation, but
the nit in me feels compelled to ask:
"100% of what?"
XSL 1.1 says for percentages in block-progression-dimension:
The percentage is calculated with respect to the corresponding
dimension
of the closest area ancestor that was generated by a block-level
formatting object. If that dimension is not specified explicitly
(i.e.,
it depends on content's block-progression-dimension), the value is
interpreted as "auto".
But that's a weird statement IMO. If the table's parent is a block,
the
block's height depends on the content's size. Circular dependency. It
would make more sense to say: "...of the closest anscestor that is a
reference area..." Shrug.
The Rec in all its glory! :)
I wonder what this means for tables that don't have a block-container
parent. Note that, since a block's b-p-d can't be specified, that
leaves only block-container as a possible and reliable base 'block-
level FO that generates the closest area ancestor'. If there is no
such block-container, the behavior of percentages would again be
undefined. If there's only a parent block, then this would create a
circular dependency, as you point out...
Besides that, mind that the native XSL property 'block-progression-
dimension' does not directly apply to table or table-row. That is,
specifying block-progression-dimension="100%" on a table or table-row
would (and should) not have any effect. Only the CSS-XSL hybrids
'height/min-height/max-height' apply to them. Now, these being CSS
properties in origin, I think that either:
a) the first rule in 7.3 applies
"1. For properties defined in CSS2 referring to the "containing
block", the content-rectangle of the closest ancestor block-area that
is not a line-area is used."
or b), the height property being mapped to XSL's block-progression-
dimension (or inline-progression-dimension), the fourth rule applies
"4. If the formatting object generating the identified area generates
a sequence of such areas, the first area is used for the conversion."
I'd put my money on a). Moreover, this is most likely why XSL
explicitly refers to CSS in its definition of height, since
percentage heights for tables and table-rows in CSS are /not/ defined
in terms of a containing block --they are undefined altogether :(
b) seems to make matters even worse. It would again lead to a
circular dependency for some tables that are direct descendants of
the flow, since that 'first area' could correspond to the first area
generated by the table itself... If not, then it could also be an
area generated by a completely unrelated block (=first block in the
flow) preceding the table...? Big Shrug indeed!
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
