On Feb 13, 2007, at 15:06, Chris Bowditch wrote:
Andreas L Delmelle wrote:
<snip/>
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...
In the case where fo:table is a child of fo:block or fo:flow isn't
the nearest ancestor reference area the fo:region-body? Whose bpd
will be known.
Yes, but that's precisely what makes it all so fuzzy...
The Recommendation does not refer to the 'nearest ancestor reference
area'.
Why? I have no idea. In any case, there's only stuff like:
- the closest area ancestor generated by a block-level FO
- the closest ancestor block-area
- the first area in the sequence of areas generated by...
All in all, I'd say it boils down to: don't use percentages for table
or table-row height (or table-cell, for that matter).
Peculiar is that the behavior for percentages on fixed-positioned
block-containers is explicitly defined in terms of references to the
nearest ancestor viewport area. OTOH, if I remember correctly, block-
containers aren't supposed to appear broken over multiple pages (if
the content is too large to fit, treat the excess content according
to the overflow property).
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
