Re: [css-multicol] Overflowing floats issue



On 4/29/13 4:31 PM, "Håkon Wium Lie" <howcome@opera.com> wrote:

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

I do not think we should require something that makes it easy to produce
large gaps in your multicol content, whether at CR or any other stage.

It's simple but it just doesn't seem right.

>
>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:55:59 UTC