Re: [css-multicol] Overflowing floats issue



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. So I don't think this is the right behavior for core
multicol use-cases; in some cases it would be though e.g. if I have a flow
of image/caption blurbs like Pinterest then what you describe is what I'd
want.


Or, as you suggest, we let authors choose and pick a reasonable default. I
just don't think the default you prefer is best for multicol.

Received on Monday, 29 April 2013 17:13:38 UTC