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

Hi,

In 3.4 Pseudo-algorithm:

> available-width: if the used width of the multi-column element has
> not been determined when the ‘column-count’ and ‘column-width’ must
> be determined (e.g., if it is floating with a ‘width’ of ‘auto’ as
> per CSS 2.1 section 10.3.5) this variable is unknown

[...]

> shrink-to-fit: this variable represents the result of a shrink-to-fit
> computation. CSS does not define the exact algorithm.


Actually shrink-to-fit is defined in CSS 2.1. It is based on the 
preferred width and preferred minimum width which, them, are note 
defined exactly:

10.3.5:

> Then the shrink-to-fit width is:
> min(max(preferred minimum width, available width), preferred width).


Note that the shrink-to-fit variable is only used in the multicol 
algorithm when available-width is unknown, but css21’s definition of 
shrink-to-fit requires a know available width. I don’t know what was the 
original intent of the spec, but clearly it doesn’t work as it stands.

Conversely, I think that the only situations where the available with 
might be unknown is when trying to determine a preferred (minimum) 
width. 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 suggest that all mention of shrink-to-fit and unknown available widths 
are removed from the multicol algorithm, and defined the preferred 
(minimum) width of multicol elements/boxes separately.

Here is a test case for preferred widths (also attached):
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.

The cases 3 and 4 are especially tricky. The algorithm currently has:

> (03)  if ((available-width = unknown) and (column-count = auto)) then
> (04)    exit; /* no columns */

Which means: when looking for the preferred (minimum) with of an element 
with auto column-count but non-auto column-width, it is not a 
multi-column element.

Later when doing the actual layout of the same element, the available 
width is known. We can either:

* Make it a multi-column element after all. I think this is bad to have 
a completely different behavior than we had for preferred widths.

* Do not make columns. I think it is bad that an element switches layout 
modes just because we looked at its preferred width at some point. 
(Because eg. it had a float ancestor with 'width: auto'.) Preferred 
widths are sometimes called intrinsic, they should not be influenced by 
an ancestor or even by available-width.

Therefore, I suggest that these two lines are removed from the 
algorithm. An element with auto column-count but non-auto column-width 
is still a multi-column element, even for the purpose of preferred 
widths. This is what Gecko does in cases 3 and 4 of the attached test.

Regards,
-- 
Simon Sapin