548871 - Width of columns with -moz-colum-width can be increased only in steps.

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Thomas Kluyver]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

Trying different widths for columns using CSS, it increases in sudden jumps, with no change between them. This appears to be the same whatever units are used for the width (tested em, px, cm). For me, there is a jump between 465 and 466 px, or equivalently between 31 and 32 em, but these values change depending on the size of the view.

Reproducible: Always

Steps to Reproduce:
1. Create a local copy of the example and its CSS.
http://tak-dev.appspot.com/lex/plos-paper.html
http://tak-dev.appspot.com/lex/main.css
2. Open the html file in Firefox.
3. Change the -moz-column-width value set in the CSS file to a range of values.
Alternatively, use Firebug to change the style of the id="content" div.
Actual Results:  
Bands of values for -moz-column-width produce the same display, and there are sharp transitions between these at particular values.

Expected Results:  
The displayed column widths should vary smoothly as the value of -moz-column-width is increased.

Something like this seems to be briefly mentioned in the CSS spec:
http://www.w3.org/TR/css3-multicol/#cw
(Example):"There is room for two 45px wide columns inside the 100px wide element. In order to fill the available space the actual column width will be increased to 50px."

In the test case, the total width is set by the columns (as in, (column-width + column-gap) * nColumns), so I don't believe that this sort of rounding should be taking place.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://www.w3.org/TR/css3-multicol/#pseudo-algorithm sends this case through the path:

(16)  if (column-width = auto) then
(27)  elsif (column-count = auto) then
(28)    if (column-width >= available-width) then
(31)    else
(32)      N := floor((available-width + column-gap) / (column-width + column-gap));
(33)      W := ((available-width + column-gap) / N) - column-gap;

which means that in this case the 'column-width' property is essentially supposed to provide a minimum width of the columns.  In other words, what it says is:  give me the most columns you can such that each column is at least 'column-width' wide, and then distribute the excess space among the columns.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, I think we're following the spec here.

Also, your explain.html says there's a known issue: "Firefox doesn't re-layout columns when you resize the window. After you resize, hit refresh to re-display it." ... but that seems to work for me.

Cool stuff!

Comment 3

[Thomas Kluyver]

Hmmm. That would seem to me to be a failing in the spec, then. Should there not be a way that a column size can be varied to whatever value I want?

The spec does mention "To set an exact column width, all length values (in horizontal text these are: ‘width’, ‘column-width’, ‘column-gap’, and ‘column-rule-width’) must be specified. " I couldn't get that to work as I expected in testing, and in any case, I'd obviously prefer not to specify a width for the div.

Even so, is Gecko really following that pseudo-algorithm? Playing about with the numbers in Firebug, I can make it jump between:
- Set -moz-column-width: 30em giving 27 columns of width 455 px
- Set 31em giving 18 columns of width 698
Oh, wait, I've spotted what's going on. The former neatly puts 3 columns into my initial view, the latter neatly puts 2. So the width of the screen is being taken as available-width in the pseudo-algorithm, although the width it ends up using is ~9 times that. It's neat, but I still think a finer-grained control would be preferable.

Robert: I can still replicate it. Specifically decreasing the height of the window leaves the columns at the previous height. Could it have been fixed between 3.5 and 3.6?

Thanks both for your prompt responses!

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #3)
> It's neat, but I still think a finer-grained control
> would be preferable.

www-style is probably the best place to discuss this.

> Robert: I can still replicate it. Specifically decreasing the height of the
> window leaves the columns at the previous height. Could it have been fixed
> between 3.5 and 3.6?
> 
> Thanks both for your prompt responses!

Decreasing the window size works for me. I'm using 3.7 trunk. I doubt we fixed anything significant here since 3.5, but maybe something improved. Try a trunk build.

Comment 5

[Thomas Kluyver]

I confirm that the nightly build I downloaded (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a2pre) Gecko/20100226 Minefield/3.7a2pre) does handle resizing correctly. So that's been resolved somewhere in the meantime.

Any word on whether taking the window width as the available width (although it ultimately uses much more) is the intended behaviour?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, that is the intended behavior for both Firefox and the CSS spec.

Comment 7

[Thomas Kluyver]

OK--thanks for your time.