Re: [css-break] slicing content

On 01/27/2015 05:19 AM, Håkon Wium Lie 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
>   - replaced content may be sliced, based on value of 'break-inside' (see below)

We do want to allow slicing, as Tab explained, in the cases where it's
not otherwise possible to fit the content.

>   > > My own suggestion would be to not allow them at all. It seems wrong to
>   > > display the upper half of a line in one column (or region, or page)
>   > > and the lower half on the next. And I'm sure many
>   > > designers/photographers would object to their images being sliced and
>   > > diced.
>   >
>   > We discussed both options and concluded that it's better to default to
>   > "no dataloss". In some cases (say, an illustrative photograph), it's
>   > not a big deal if half the image doesn't show up. But in others (a
>   > graph, a map, a diagram) it's much more important that the image be
>   > entirely present, even if it is broken across two pages because it
>   > won't fit on one page.
>
> I can see the need for both cases, although my default would be to
> clip -- my mind is not able to splice the stripes together and I would
> most likely misread any sliced diagram. And sliced line boxes makes my
> head hurt even more.

Default should be no dataloss. Dataloss as a side-effect of layout
should always be opt-in, if we can make it so.

> BTW, The issue was first reported for SVG:
>
>    https://code.google.com/p/chromium/issues/detail?id=260071
>
>   > (We do require that you try to keep it together, just as if break-inside:
>   > avoid had been specified! So the break will only be introduced if there
>   > would otherwise be dataloss. If you can push it to the next page and not
>   > introduce a break, then you must do that.)
>
> The above text is much more clear than the current spec. If this is
> what the spec attempts to say, I suggest using the above text.

Okay. I can't really copy-paste that paragraph into the spec, but
how's this? Last paragraph in
   http://dev.w3.org/csswg/css-break/#unforced-breaks

  # Finally, if there are no possible break points below the top of the
  # fragmentainer, and not all the content fits, the UA may break anywhere
  # in order to avoid losing content off the edge of the fragmentainer.
  # In such cases, the UA may also fragment the contents of monolithic
  # elements by slicing the element’s graphical representation.

See
   http://dev.w3.org/csswg/css-break/#possible-breaks
for the definition of monolithic elements.

>   > > However, if do allow break points inside line boxes and/or images, we should
>   > > probably have a way of turning slicing off.
>   >
>   > Perhaps a 'break-inside: forbid' value? That would prevent breaking and
>   > require the item to clip at the edge of the fragmentainer?
>
> I think it can be expressed without adding a new value. We could simply say:
>
>    break-inside: avoid; /* prohibits slicing */
>    break-inside: auto; /* allows slicing */

The problem with this is that it doesn't work well with

   a) fallback content -- the break-inside value is still in effect,
      even though you may not want that when the image falls back to
      some alternate content

   b) non-<img> replaced content -- with generated content, we can
      insert images into the content that wouldn't be targetted by
      the UA style rules that assign 'break-inside: avoid'

Since the initial value is 'auto', it makes sense that its behavior
varies by context. What we can do is add a future value that allows
monolithic content to slice. Since we're not 100% sure about what
that value would be and how it would interact with other breaking
rules, though, we're deferring this particular feature to the next
level. See minutes at

   https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html

>   > My concern
>   > is that in most cases where we are running into this problem, it's because
>   > the author didn't think about their design very carefully. For example,
>   > s/he could have specified
>   >
>   >    @media print {
>   >       max-height: 100vh;
>   >       max-width: 100vh;
>   >    }
>
> Yes, this would force the image (or something) over to the next
> column. Possibly leaving the previous column with only one line of
> text, thereby wasting white space.
>
>   > in order to make sure the item fits on a page. Or do something else.
>   > I'm having trouble thinking of a case where the author would actually
>   > want the image to clip at some random point depending on the paper/
>   > ereader/screen size.
>
> If the image isn't central to the text, and is clickable if you really
> want to see it, and you don't like seeing pages that are mostly
> wasted.
>
> I agree that clipping images in random locations is not optimal. But
> often more optimal than confusing users with images sliced in random
> locations.

Again, the default behavior should be no dataloss, on principle.
If we want other behaviors, we can make those opt-in. Ugly info
wins over missing info--at least if you don't know whether the
info is important. (And by default, we don't know that.)

~fantasai

Received on Thursday, 16 July 2015 21:14:22 UTC