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

[CSS 2.1] Section 13.3 Page-breaks

From: Allan Sandfeld Jensen <kde@carewolf.com>
Date: Sat, 1 Sep 2007 08:50:47 +0200
To: www-style@w3.org
Message-Id: <200709010850.47202.kde@carewolf.com>

I apologize for writing a comment this late, but I has taken me quite some 
time to wrap my head around this.

First in section 13.3.1 the property page-break-inside. I actually don't think 
that it should be inherited. The fact that is has been set to inherited right 
now is a misunderstanding of its effect.
There is a difference between CSS properties that are value inherited, and CSS 
properties which has an effect that naturally applies to its children as 
well. For instance display:none is inherited in effect, but not as a 
property. I think page-break-inside should belong to this category.

If you let page-break-inside be inheritable, it naturally implies that you can 
overrule it in a child element. For instance by making a <PBR> page-break 
element. This also means that when you are scanning the document for the best 
page-break opportunities, you can not rely on the it to be true for the 
entire block, and need to scan all children to see if any of them contains 
better page-break opportunities than their parent.

If you let page-break-inside instead apply to all children without being 
inherited, you can calculate an accumulative effect. When evaluating 
the 'best' page-break you can find the one that violates the fewest number of 
page-break-inside:avoid. 

In a previous reply 
http://lists.w3.org/Archives/Public/www-style/2007Apr/0036.html , it was 
stated it was thought uncommon that a page-break-inside would be big and need 
page-breaks. I disagree, though mostly because I choose to treat elements 
with borders as page-break-inside: avoid. 

You should always avoid to break borders, and this includes breaking inside 
their children because that too would break the border. In this way it is an 
inherited page-break avoid 'effect' that you need to track. Pages with long 
borders that you need to break is unfortunately very common, so it is 
something you have to handle nicely. One nice rule to apply is to be 
break 'as few' borders as possible. In other words if you need to break an 
implied page-break avoid you want to break as few as possible.

So this is actually an algorithm you need to implement anyway, and there is no 
good reason not to handle page-break-inside the same way. Elements that have 
border and elements that would be set to page-break-inside has much in 
common, and having to different page-break-inside avoid effects would be 
confusing.

Though late, I think it is pretty safe to change the description of 
page-break-inside to be an inherited effect instead of inherited as a 
property. The page-breaking part of CSS 2.1 is still the least specified, and 
one of the parts not implemented in multiple compatible versions. Especially 
this page-break-inside stuff doesn't work right anywhere.  

You could also leave it ambiguous and under-specified and fix it later in CSS 
3 Page. 

Regards
`Allan Sandfeld
Received on Saturday, 1 September 2007 06:51:03 GMT

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