RE: [css3-multicol] floats that overflow columns

Fantasai, thanks for adding a title for me.

I am not sure if your preference is for multicol in particular or for future page floats too. I am guessing it is the latter.

Yes, it is easier to get a more deterministic layout if circular dependencies (like displacing already processed content) are avoided. However
(a) it creates lack of symmetry which will be confusing; even defining "left" and "right" in this context can be a challenge
(b) such layout circular dependencies are already inevitable for what page floats are trying to do

>From my experience these circular dependencies are not hard to resolve; they may need certain support in layout architecture because multiple passes are needed for some calculations, but it is resolvable and can still be deterministic.

That said, my preference is for keeping muticol just about multicol, and dealing with new kinds of intrusions as a separate feature in GCPM (and I am not proposing any changes there).

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Monday, August 10, 2009 1:23 PM
To: www-style@w3.org
Subject: Re: [css3-multicol] floats that overflow columns

Alex Mogilevsky wrote:
> 1)      In [multicol] spec, remove special treatment for overflow of
> floats. Overflow floats should be clipped to the column exactly as any
> other kind of overflow would. This way, content that was initially
> designed for single-column layout has same behavior.
>
> 2)      Leave definition of floats that intrude across columns to GCPM
> [2]. In fact, page floats as currently defined in GCPM are powerful
> enough to work as shown in [1].

I think I would prefer if instead of 1) we let floats intrude into later columns, but not into earlier columns. I.e. floats can intrude into other columns, but they always overflow the end edge, never the start edge, of their block. I'm not sure how hard it would be to handle that sort of clipping behavior, but the layout part is straightforward.

~fantasai

Received on Monday, 10 August 2009 22:39:31 UTC