Re: [css-multicol] Overflowing floats issue

Sylvain Galineau wrote:

 > On 4/29/13 1:58 AM, "François REMY" <francois.remy.dev@outlook.com> wrote:
 > 
 > >> > The UA is not required to fragment the contents of monolithic
 > >> > elements, and may instead either slice the element's graphical
 > >> > representation as necessary to fragment it or treat its box as
 > >> > unbreakable and overflow the fragmentainer.
 > >
 > >It seems like a major undefined-ness source to me. I would prefer the
 > >behavior to be more clearly defined. When people will use CSS Regions or
 > >use columns, they will not expect browsers to act completely differently
 > >when elements overflow. Even in the case of printing, if we someday want
 > >HTML to become the universal printing format to replace PDF/XPS, we don't
 > >want it to leave up to the printer the responsability to decide where to
 > >page-break your content.
 > >
 > >I stand by my position that unbreakable overflowing elements should be
 > >sent to the next fragmentainer in all cases and, if they are still bigger
 > >than the next fragmentainer, then they should overflow.
 > 
 > It's not quite undefined-ness since the spec does describe two behaviors.
 > But yes, to the extent either rendering is valid then interop suffers. The
 > behavior you suggest - stop text flow, move image to next column, resume
 > text flow - is very simple and predictable but does not sound right to me:
 > it would easily produce ugly empty space in any kind of mixed text
 > content, something you never see in print and arguably do not want to see
 > on the web either.

I agree that the rendering you describe in the last paragraph looks
better. Implenting it is harder, though. GCPM adds levers to control
this; one casn say that floats should go to the top or bottom of a
column:

  img { float: top }
  .figure { float: bottom }

or snap to the nearest edge:

  img { float: snap }

The draft spec is here:

  http://dev.w3.org/csswg/css-gcpm/#floating-to-the-topbottom-top-bottom-sna

Screenshots from an initial implementation are here:

  http://people.opera.com/howcome/2013/02-reader/#dictionary

I suggest that the multicol specification remains silent on the issue
of content reordering, even if it means that implementations will
differ. There are two main reasons for this: (a) the spec is in CR, an
(b) the prioblem is identical in pages, and CSS2.1/css3-page are
silent on this issue.

If we decide to say something, I think François's simple alternative
is the only we can require.

On the issue of clipping, I'd say floats should either:

 (a) be clipped like content in the normal flow
 (b) if it isn't clipped, it should push aside content in other columns

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

Received on Monday, 29 April 2013 23:32:31 UTC