Re: keep-*="always" seems to be ambiguous

Thanks, Fabio. I guess that makes sense. I didn't think about the
passage in chapter 3. Thinking some more about this I'd say it probably
makes sense to treat "always" as "always" and handle the overflow based
on the respective property on region-body, i.e. fail if
overflow="error-if-overflow" or simply overflow or clip. If someone
wants to have the keeps relaxed one has to use an integer value. This
allows for maximum flexibility.

On 12.07.2006 17:16:57 Giannetti, Fabio wrote:
> 
> Jeremias,
>   both the behaviours are valid and compliant with the specs.
> 
> "1. keep conditions with a strength of "always" may never be relaxed
> simply based on the value's name: "always". Only numeric keep strengths
> may be relaxed."
> 
> This behaviour is supported by:
> 
> 4.8 Keeps and Breaks
> 
> Keep conditions are imposed by the "within-page", "within-column", and
> "within-line" components of the "keep-with-previous", "keep-with-next",
> and "keep-together" properties. The refined value of each component
> specifies the strength of the keep condition imposed, with higher
> numbers being stronger than lower numbers and the value always being
> stronger than all numeric values."
> 
> Stating that "always" has to be considered the highest priority.
> On the other hand in:
> 
> 3 Introduction to Formatting
> 
> Formatting is the process  ....
> Constraints might conflict to the point where it is impossible to
> satisfy them all. In that case, it is implementation-defined which
> constraints should be relaxed and in what order to satisfy the others.
> 
> the case where the keep generates an overflow, put the rendering engine
> in an over-constrained situation. This means that is up to the rendering
> engine to decide which is the most appropriate action to execute, so
> the:
> 
> "2. keep conditions with a strength of "always" may be relaxed if they
> cannot be satisfied."
> fall in this scenario.
> 
> Hope this helps,
> Fabio Giannetti


Thanks,
Jeremias Maerki

Received on Thursday, 13 July 2006 11:30:42 UTC