Thanks, Luca. It does make sense but I'm having trouble mapping your interpretation to what is written in the spec. I wonder: Do you agree with me that my second example wouldn't be affected by the rules described in 4.3.2?
Anyway, I think I'm going to let this rest and instead concentrate on detecting overflow situations. After all, this stuff here seems pretty exotic. On 09.12.2005 14:40:01 Luca Furini wrote: > Jeremias Maerki wrote: > > > You will have seen that I've been working on overconstrained documents. > > 5.3.4 Overconstrained Geometry is more or less implemented, so now I > > need to have a look at 4.3.2 which proves quite difficult to understand. > > At least I can't make much sense of it ATM. > > > > [...] > > > > If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about > > I'd love to read your thoughts. Otherwise, I will run this through the > > XSL editors list. > > I always thought (probably wrongly) these sections of the spec refer to > the page regions, maybe because of the property display-align, and more as > a way to "formally justify" what is usually done than as prescribing some > particular behaviour. > > To be more clear (I hope :-)): region viewports usually have a well-known > height (unless there is only a single page whose height is unbounded); > their area children don't always fill them completely. The content areas > are placed at the top / center / bottom of the viewport according to the > value of display-align: but, as these extra spaces may be in contrast with > the space properties of the first and last child areas, we need, from a > formal point of view, a rule saying that we are allowed to do this, > otherwise the specs would be inconsistent. > > In other words, I always read these rules as: "spaces added ad the top / > bottom of a page to implement display-align have greater precedence than > space-before or space-after traits of the child areas". According to me, > rule 4 should state something like this: "the maximum value of the > space-specifier is set to the difference between the containing height and > the content height". > > Don't know if this makes any sense ... > > Regards > Luca Jeremias Maerki
