W3C home > Mailing lists > Public > www-style@w3.org > January 2015

Re: [css-break] slicing content

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 27 Jan 2015 10:15:07 -0800
Message-ID: <CAAWBYDDTkpswKPoL0L_Gn1zqCLRR=yW_aeLohj-W4sG6Sm+mjQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:56 UTC