Re: [css-break] slicing content

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)

 > > 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.

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.

 > > 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 */  

 > 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.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Tuesday, 27 January 2015 10:20:21 UTC