Re: [css3-multicol] unknown available width and shrink-to-fit

Le 26/09/2012 21:09, Håkon Wium Lie a écrit :
> [...]
>
> But it's two different widths. In CSS 2.1, the "available-width" is
> the width of the containing block of the float. In CSS3-multicol, the
> "available-width" is the used width of the multi-column element
> itself. So I don't think there is a circular dependency.

Okay. That may be the source of my misunderstanding. But shrink-to-fit 
*is* the same as defined in §10.3.5 of CSS 2.1, isn’t it?


>   > Conversely, I think that the only situations where the available with
>   > might be unknown is when trying to determine a preferred (minimum)
>   > width.
>
> Really? The example used in the CSS3-multicol is this:
>
>    .multicol { width: auto; float: left }

Yes, precisely. The used width of a float with 'width: auto' in CSS 2.1 
is based on the (containing block’s) available width as well as the 
float’s preferred width and preferred minimum width.

But let’s take a step back for a bit. When exactly is the multicol 
pseudo-algorithm used? In particular, what does "if the used width of 
the multi-column element has not been determined when the ‘column-count’ 
and ‘column-width’ must be determined" mean?

My understanding of CSS 2.1 is that the used value for 'auto' widths is 
always (more or less directly) based on the containing block’s width. 
Some cases (floats, abspos, tables) are also based on the content’s 
intrinsic widths (minimum and preferred). Implementations must do a 
first pass on the box tree to determine these intrinsic widths 
(independently of the width of any containing block), then do the 
"shrink-to-fit" dance to determine the used width, and only then do a 
second pass to do the actual layout of the content.

How does multicol fit into this? When must the used values of 
‘column-count’ and ‘column-width’ be determined? In which of these cases 
is the used width not know (yet)? Is the algorithm run again later when 
the used width is decided?

Please help me understand what is the intended behavior in the spec, so 
I can revisit my proposal.


> Arguably a corner case, but I thik we should define it.

My suggestion to make it undefined was only an attempt to make the 
proposal "lighter", since the first email did not get any response in 
almost two months. I also think it should be defined. I’m fine with 
defining it later if we’re not sure how to, but do not want to block 
multicol level 3.


>   > These are generally based recursively on the preferred outer
>   > widths of the content. In the multicol case, I think that the content
>   > should be the basis for the width of a single column, not for the whole
>   > multicol element as the pseudo-algorithm seems to imply.
>
> I believe the intention of having these lines in the algorithm:
>
>    if (available-width = unknown) then
>       available-width := shrink-to-fit;
>
> is that floats should not change in width if/when they are/become multicol.
>
> That is, these two elements should have the same width:
>
>    one { width: auto; float: left; column-width: auto; column-count: auto }
>    two { width: auto; float: left; column-width: auto; column-count: 2 }

Should they? If W is the preferred minimum width width so that the 
content on one column (not multicol) does not overflow, I think that the 
width of a two-column float with the same content should be at least 2*W 
(assuming column-gap: 0, for simplicity).

My test shows little to no interop, so I guess we can spec whatever we 
think is best.

Le 25/07/2012 15:41, Simon Sapin a écrit :
> http://result.dabblet.com/gist/3176157/
>
> I tried it in Firefox 14, Chromium 20 and Opera 12. There is little
> interoperability. In the test I described the behavior that I think is best.

-- 
Simon Sapin

Received on Thursday, 27 September 2012 09:31:51 UTC