W3C home > Mailing lists > Public > www-style@w3.org > April 2013

RE: [css-multicol] Overflowing floats issue

From: François REMY <francois.remy.dev@outlook.com>
Date: Mon, 29 Apr 2013 10:58:10 +0200
Message-ID: <DUB120-W9E3CE8FE0D4402D6994C1A5B20@phx.gbl>
To: Simon Sapin <simon.sapin@exyr.org>, "www-style@w3.org" <www-style@w3.org>
> > 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. 

This behavior could possibly be altered by a property that would allow an element to be fragmented as pixel stream the way Chrome is doing with images (why not 'break-inside: as-replaced-element), but I don't believe this should be the default behavior nor that it should be allowed to be just that.



> > Content in the normal flow that extends into column gaps (e.g., long
> > words or images) is clipped in the middle of the column gap.
>
> But "in the normal flow" does not apply to your floating image.

I believe the aim was to include floating content, but you're right the wording wasn't clear enough. I would approve a clarification that explains this statement also applies to floating elements. 		 	   		  
Received on Monday, 29 April 2013 08:58:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2013 08:58:37 UTC