W3C home > Mailing lists > Public > www-style@w3.org > July 2013

RE: [css-break] another fragmentation question

From: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 19 Jul 2013 01:03:09 +0200
Message-ID: <DUB120-W34D45D5346FBB124816910A5620@phx.gbl>
To: Morten Stenshorne <mstensho@opera.com>
CC: "www-style@w3.org" <www-style@w3.org>
>> 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 Gecko is right, and that WebKit and Presto are wrong. Breaking
> inside padding and borders should be avoided.
>
> http://dev.w3.org/csswg/css-break/#possible-breaks
>
> Gecko uses a class 2 opportunity (between the two line boxes). There are
> no class 1 or 3 break opportunities in the test case.

Thank you for your answer. This is how I was reading it as well. 

However, I don't think there's such kind of "prefer (1) to (2) to (3)" rule, so as soon as the browser finds all the breakpoints that are possible, it may use them in any priority order. I guess the rule chosen by the other browsers is "find the break point that's the nearest the point you have to break anyway" which is why they end up breaking inside the padding or border.

What I find strange in the Gecko behavior is the way the break is vertically "extended" to make the box fit the column. I can't find that in the spec anywhere, nor does it seems very logical to do so. 		 	   		  
Received on Thursday, 18 July 2013 23:03:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC