- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 27 Jan 2015 10:15:07 -0800
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Tue, Jan 27, 2015 at 2:19 AM, Håkon Wium Lie <howcome@opera.com> wrote: > fantasai wrote: > > > > http://www.wiumlie.no/2014/tests/multicol-clip.html > > > > So, I'd like to clarify where/if break points can be added inside line > > > boxes and images. > > > > They're not really fragmentation break opportunities in the sense that > > the layout will reflow around the break, but it is allowed to "break" > > the content by slicing it if it won't otherwise fit on a single page. > > I'm not sure I follow. Either slicing should be listed as a break, or > not. As it stands, the specifiction lists breaks, and then adds > slicing (which basically allows UAs to break any content whereever > they want without regard for the listed breakpoints) as an optional > afterthought. > > I suggest saying that: > > - line boxes should never be sliced, and that What happens, then, when a linebox is larger than the entire fragmentainer? This can happen, for example, when printing a poster across several sheets of paper. If they're not sliced, the overflow is just dropped, which isn't useful. > - replaced content may be sliced, based on value of 'break-inside' (see below) Yeah, based on your argument down below, it does seem reasonable to allow authors to opt-in to having their replaced elements sliced wherever (current WK/B default behavior). Otherwise, the behavior of "only slice if moving it to the next fragment wouldn't help" seems like the right default. ~TJ
Received on Tuesday, 27 January 2015 18:15:54 UTC