Re: [css-multicol] Overflowing floats issue

Le 29/04/2013 10:58, François REMY a écrit :
>>> 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.

I don’t see a reason to leave this undefined, and I agree that the 
behavior you describe would be preferable.


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

"In-flow" is defined in CSS 2.1 and clearly does not apply to floated 
elements. But we could could change the spec to say "Floated or in-flow 
content that extends …"

http://www.w3.org/TR/CSS21/visuren.html#x24

-- 
Simon Sapin

Received on Monday, 29 April 2013 09:24:54 UTC