RE: [css-break] breaking inside padding

± On 07/18/2013 03:03 PM, François REMY wrote:
± > Hi,
± >
± > Here's another css-break question to queue into your "to-look-at" list.
± > This time, I would like to understand whether the Gecko behavior is
± > valid according to the fragmentation spec or not.
± >
± > The test case contain a single block element whose vertical padding
± > makes it too tall for a fragmentainer.
± >
± > Most browsers agrees that the break happens at the pixel line where
± > the bottom padding starts to be too tall, but Firefox does make use a
± > line break inside the block element itself in a way that looks odd to
± > me.
± 
± I think Morten explained clearly why this is correct per spec. I'll try to explain
± why this is the behavior chose by the spec. :) It looks weird in testcases, and
± possibly some layout applications. But consider, for example, an instruction
± book with a warning box. It has a bright red border and some padding to give
± space between the text and the border. It would not make sense to break
± inside the padding, pushing just a portion of the border to the next page. It
± makes more sense to split the box between line boxes, including some
± content on each page.
± 
± If it's important and desired for authors to be able to break inside the
± padding for some reason, I'd like to see some use cases. We could then allow
± it by allowing widows/orphans: 0 to enable such behavior.
± (Right now the minimum is 1, which matches to the behavior you are
± seeing: including at least 1 line of content before the end of the
± block.)

Thanks for reviewing the [css3-break] issues, this is valuable work.

I think we should have two modes for [css3-break]: 
- fragmentainer-overflow: avoid // default on almost everything
- fragmentainer-overflow: none // default on printed @pages

When "fragmentainer-overflow: none" is set, it is simply forbidden for an element to overflow its fragmentainer. In case the first breaking point available would result in an overflow of the content out of the fragmentainer, the "bitmap-based" algorithm we currently see in browsers except FireFox would apply.

It seems clear to me that, when printing, the desire is to avoid printing off-page which is why browsers fragment according to this pixel-line break.

Thoughts?

Received on Friday, 13 December 2013 08:38:47 UTC