W3C home > Mailing lists > Public > www-style@w3.org > March 2007

[CSS 2.1] Section 13.3.3 Allowed page breaks inconsistent

From: Grant, Melinda <melinda.grant@hp.com>
Date: Fri, 16 Mar 2007 01:39:49 -0000
Message-ID: <78A3602ADF54BA4EAB53F378BF55588BE73060@G3W0067.americas.hpqcorp.net>
To: <www-style@w3.org>


What is the intent wrt CSS 2.1 Section 13.3.3 Rules A-D regarding the
relationship between an element whose 'page-break-inside' property value
is 'avoid' and descendants whose values are 'auto'? 

Page-break-inside is inherited, so it's easy enough to set 'avoid' on a
portion of a document tree.

When a child within such a section is explicitly set to 'auto', a break
opportunity is established between line boxes of the child. (Rule D)

However, when two adjacent child blocks are set to auto, the break
opportunity between them is overruled by the parent. (Rule B)

This lack of parity seems undesirable.  Either 'auto' should be allowed
to override ancestors with 'avoid', or it should not.  Am I missing some
use case that would justify this difference in behavior between breaks
between blocks versus breaks within blocks?

I would suggest either:

            Removal of Rule B -- allow descendants to create a break
opportunity when they are explicitly set to 'auto'.

Or

            Modification of Rule D to constrain elements to not override
their ancestors' 'page-break-inside: avoid' property.  E.g., "Rule D: In
addition, breaking at (2) is allowed only if the 'page-break-inside'
<http://www.w3.org/TR/CSS21/page.html#propdef-page-break-inside>
property is 'auto' for the element and all its ancestors."

Or are there better ways to address this inconsistency?

I think the question is, should an author be able to suspend
'page-break-inside: avoid' for some elements within such a block, or
not?

Best wishes,

Melinda

  _____ 

HP  -   Melinda Grant
Connectivity Standards 
Consumer Printing and Imaging
+1 (541) 582-3681
melinda.grant@hp.com   
  _____ 
Received on Friday, 16 March 2007 01:40:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:50 GMT