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

RE: [CSS 2.1] Section 13.3 Page-breaks

From: Alex Mogilevsky <alexmog@exchange.microsoft.com>
Date: Sat, 1 Sep 2007 22:52:38 -0700
To: Allan Sandfeld Jensen <kde@carewolf.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <04F36FB4ED0F85459AA447F72711526FFF58F9487D@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I think what you are suggesting is treating page-break-inside as background or borders. The whole element has a property, it has an effect on children but the children don't need the property.

It is certainly an attractive idea to treat an element with page-break-inside:avoid as an unbreakable box, but there are issues with that:

* page-break-before:always on a child element takes priority over parent's "avoid", so content has to be scanned anyway
* CSS3 adds "allow" value, which also overrides container's "avoid"

Making page-break-inside an "effect" would work pretty much the same way, but it is in fact more work in implementation. Unlike background, the effective value is analyzed at each line, which means it has to be passed down through layout process, which is same as inheritance.

There is a subtle difference between "effect" and inheritance. As currently defined, in this example breaks are allowed in the inner div

<div style="page-break-inside:avoid">
   <div style="page-break-inside:auto">breaks are allowed here</div>
</div>

It this case "auto" has same effect as "avoid". Removing inheritance would fix this case, but it would make more common cases harder to define and implement, which is why exactly this change was rejected on F2F this March.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Allan Sandfeld Jensen
> Sent: Friday, August 31, 2007 11:51 PM
> To: www-style@w3.org
> Subject: [CSS 2.1] Section 13.3 Page-breaks
>
>
> 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 Sunday, 2 September 2007 05:52:55 GMT

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