W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css3-multicol] updated editor's draft

From: Morten Stenshorne <mstensho@opera.com>
Date: Wed, 22 May 2013 20:57:46 +0200
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org, Håkon Wium Lie <howcome@opera.com>
Message-ID: <87li76kfkl.fsf@aeneas.oslo.osa>
Bert Bos <bert@w3.org> writes:

> On Wednesday 15 May 2013 16:57:47 Morten Stenshorne wrote:
>> Håkon Wium Lie <howcome@opera.com> writes:

>> I think the pseudo algorithm from line 03 can be simplified to
>> something like this:
>> 
>> (03) if (column-width = auto)
>> (04)   N := column-count;
>> (05) else
>> (06)   N := floor((U + column-gap) / (column-width + column-gap))
>> (07)   if (column-count != auto)
>> (08)     N := min(column-count, N)
>> (09)   endif
>> (10)   N := max(1, N)
>> (11) endif
>> (12) W := max(0, (U + column-gap) / N - column-gap)
>> 
>> This should give the exact same results, with no code duplication.
>
> I have a preference for pure formulas, instead of variables that change 
> value, because this might well be implemented in Lisp or Prolog instead 
> of C. (Lines 12 & 13 were split only because the formula was too wide 
> for my window...) How to optimize for speed, for size, or for something 
> else, is up to the programmer.
>
> Note, e.g., that in some cases it is not necessary to compute the max() 
> in your last line, because the expression cannot be negative. Whether it 
> is worth optimizing for that is another question...
>
> Apart from this max(), the W is indeed the same in all three cases, so 
> how about showing just the three cases for N, like in your version, but 
> purely declaratively, and then the W separately:
>
>     if column-width = auto then
>       N := column-count
>     else if column-count = auto then
>       N := max(1, floor((U + column-gap)/(column-width + column-gap)))
>     else
>       N := min(column-count, max(1, 
>         floor((U + column-gap)/(column-width + column-gap))))
>
>   And:
>
>     W := max(0, ((U + column-gap)/N - column-gap)

Looks good.

>> >   - these assumptions:
>> >       -- that the block direction is unconstrained
>> >       -- that no column breaks are added through style sheets
>> 
>> The used value of column-width isn't affected by breaks or block
>> direction restrictions, but used column-count may be, but that
>> depends on what "used" means in this case. The column-count property
>> has the following phases:
>> 
>> - Specified/computed (whatever the stylesheet or style attributes
>> says)
>> 
>> - After running the pseudo algorithm
>> 
>> - Actual layout
>> 
>> Consider this example:
>> 
>> <body style="width:600px;">
>>   <div style="column-width:200px; column-gap:0; height:2em;
>> line-height:1em;"> line<br>
>>      line<br>
>>      line<br>
>>      line<br>
>>      line<br>
>>      line<br>
>>      line<br>
>>    </div>
>> </body>
>> 
>> The computed value of column-count is auto.
>> The pseudo algorithm resolves column-count to 3.
>> Layout ends up with 4 columns, due to restricted height.
>> 
>> What if we define it so that *used* column-count in the example above
>> is 3, while *actual* column-count is 4 [1]? If we do that, you can
>> remove the assumptions.
>> 
>> [1] http://www.w3.org/TR/CSS21/cascade.html#value-stages
>
> That sounds attractive. Does it influence anything else apart from the 
> terminology in the spec?

No, it shouldn't.

>> Also, it should be mentioned that the pseudo algorithm needs to be
>> run separately on each column row, since the available width in
>> different rows may vary (different page sizes, regions, what not).
>
> Isn't that already covered by the line "In paged media, user agents may 
> perform this calculation on a per-page basis"? Or do you mean that the 
> "may" should be a "must"?

D'oh, I must have ignored that line. :) Sorry. Yes, that looks fine for
now.

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23692400 ------ Mobile: +47 93440112 ----
------------------ http://www.opera.com/ -----------------
Received on Wednesday, 22 May 2013 18:58:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 May 2013 18:58:15 UTC