On 13.02.2007 13:40:53 Andreas L Delmelle wrote: > 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.
My first reaction was: That's simply not true. b-p-d does apply to table and table-row. The CSS properties are mapped to the XSL equivalents as specified in http://www.w3.org/TR/xsl11/#d0e4413 Our code exclusively works with b-p-d and i-p-d, not height, max-height etc. But as you noticed 7.3 refers to the CSS properties explicitely. IMO that's another point in the spec that is really not helpful. Rather the opposite. I wish the CSS dependency were never introduced.... Anyway, b-p-d does apply to table and table-row. :-) > 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 :( I prefer to ignore the CSS stuff and work with the XSL stuff entirely, i.e. map everything to XSL and go from there. Makes my brain hurt a little less. :-) > 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! Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
