Re: [css3-multicol] available-width = unknown and shrink-to-fit with spanning element

Le Mer 21 août 2013 4:17, Morten Stenshorne a écrit :
> "Gérard Talbot" <www-style@gtalbot.org> writes:
>
>> [test]
>> http://test.csswg.org/source/contributors/opera/submitted/multicol/multicol-span-all-margin-nested-003.xht
>>
>> In this test, the available width is unknown. So, we start with
>>
>> (09)  if (available-width = unknown) then
>> (10)    available-width := shrink-to-fit;
>> 3.4. Pseudo-algorithm
>> http://www.w3.org/TR/css3-multicol/#pseudo-algorithm
>
> Note: you should probably take a look at
> http://dev.w3.org/csswg/css-multicol/#pseudo-algorithm instead. There's
> really no need to define shrink-to-fit behavior right here,

Hmm...

So, Basic Box Model [CSS3BOX] or the Intrinsic & Extrinsic Sizing Module
[CSS3-SIZING]) is expected to define how to get the used width (U) of the
multi-column element... so that user agents can then enter line (11)

(11)  W := max(0, ((U + column-gap)/N - column-gap))
http://dev.w3.org/csswg/css-multicol/#pseudo-algorithm

and then establish the used width of each column box.


> so the new
> version is much simpler. The resulting layout from the new algorithm
> should be 100% identical to what's in the current WD, though.
>
>> and then follow and apply:
>>
>> shrink-to-fit width is:
>>
>> min(max(preferred minimum width, available width), preferred width).
>>
>> http://www.w3.org/TR/CSS21/visudet.html#shrink-to-fit-float
>
> Note again: http://dev.w3.org/csswg/css-sizing/#multicol-intrinsic is
> work in progress to define shrink-to-fit (and similar stuff) for
> multicol better.
>
>> in which case:
>>
>> min(max(preferred minimum width, available width), preferred width)
>> min(max(4em, body's available width), 19em)
>> min(body available width, 19em)
>> and so shrink-to-fit width should be 19em (which is 4 FAIL words
>> separated
>> with 3 preserved white spaces).
>>
>> Then what do we do with the rest of the pseudo-algorithm? Should we
>> continue with calculation of column box width?
>>
>> (13)    W := max(0, (available-width - ((N - 1) * column-gap)) / N);
>>
>> I ask because the reftest
>> http://test.csswg.org/source/contributors/opera/submitted/multicol/multicol-span-all-margin-nested-3-ref.xht
>> for the test gives a total width for the multi-column of 22em and not
>> 19em. So where does such 22em comes from? Normally, the available-width
>> includes the column-gapS: that's why the equation at line 13 substracts
>> the column-gapS before dividing by number of columns.
>>
>> If 19em should be the correct width for the black rectangular area, then
>> (after adding -webkit- vendor prefix) Chrome 28 would pass that test .
>
> 19em sounds like a nice width indeed, but I'm not sure if any spec can
> be interpreted to that effect (19em sounds like the correct minimum
> content measure of the multicol). For the maximum content measure, you
> seem to be supposed to assume that none of the soft break opportunities
> become actual breaks.

When I enter the proposed shrink-to-fit width equation
http://www.w3.org/TR/CSS21/visudet.html#shrink-to-fit-float
then I indeed assume that none of the soft break opportunities
become actual breaks when establishing what the available width is in the
shrink-to-fit width equation.

In

shrink-to-fit width is:
min(max(preferred minimum width, available width), preferred width)

preferred minimum width is 4em: that is the 4 FAILs words with all white
space being treated as line breaks: "preferred minimum width, e.g., by
trying all possible line breaks."

available width is body's width: "available width: in this case, this is
the width of the containing block minus the used values of 'margin-left',
'border-left-width', 'padding-left', 'padding-right',
'border-right-width', 'margin-right', and the widths of any relevant
scroll bars."

preferred width is 19em: "preferred width by formatting the content
without breaking lines other than where explicit line breaks occur"



> So you have the text "FAIL FAIL FAIL
> FAIL". Including the spaces, that would become a 19em wide line. Presto
> (where the test passes) does this and then adds the 3 column gaps (1em
> each) -> 22em. That doesn't seem right.

I agree; how Presto calculates all this (adding up to the 22em sum) does
not seem right.

Intuitively speaking, I would take the whole inline content, then treat
each white space as a line break occurence and then set the width of each
column box to the largest non-broken string and then establish the used
width of the multi-column element. So, if the longest non-broken word is
10 characters long, then each column box would be the used width of such
10-character-non-broken word; for Ahem font, it would be 10em wide.

> The intrinsic/extrinsic sizing
> spec seems to suggest a different behavior, though:
>
>    The max-content measure of a multi-column element with unrestrained
>    column heights and a computed ‘column-count’ not ‘auto’ is its
>    ‘column-count’ multiplied by the larger of its ‘column-width’
>    (treating ‘auto’ as 0) and the largest max-measure contribution of
>    its contents.


http://dev.w3.org/csswg/css-sizing/#multicol-intrinsic

<deep breath> I would need to carefully examine all this...

> The largest max-measure contribution

§4.2 defines "largest max-measure contribution" for an inline non-replaced
box. Wow.. this is really becoming thorough.

If a word was very long, say, desoxyribonucleid (17 characters long and
without hyphen), then it would make sense to say that the largest
max-measure contribution inside an multi-column element is 17em (for
simplicity here, I postulate that each and all single character are
exactly 1em wide). But when shorter words are separated by white spaces,
such white spaces should be, in my opinion, considered as normal,
expectable line break opportunities.

> would be 19em ("FAIL FAIL FAIL
> FAIL"). So you need to multiply this by 4 (number of columns), and you
> get 76em. Then you should probably add gaps as well (although the spec
> fails to mention it) -> 79em! Whoaa! But that's actually exactly how
> much you need if you don't want any line breaks.

All this (section 4.2
http://dev.w3.org/csswg/css-sizing/#inline-intrinsic and section 4.5
http://dev.w3.org/csswg/css-sizing/#multicol-intrinsic
which I have only skimmed over
) still does not give a definitive value to used width of multi-column
element.

>
>> ---------
>>
>> I have been working on 2 other versions/variations [1] of that test. I
>> can
>> see what Chrome 28 and Opera 12.16 do ... but I can not figure out which
>> one is right or wrong: any of the 2 could be right or wrong. I think the
>> pseudo-algorithm needs some tuning here.
>>
>>
>>
>> [1]
>> [test variation A]
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/multicol-span-all-margin-nested-003-GT.xht
>>
>> [reftest variation A]
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/multicol-span-all-margin-nested-003-GT-ref.xht
>>
>>
>> [test (old version)]
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/multicol-span-all-margin-nested-003-GT-previous.xht
>>
>> [reftest (old version)]
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/multicol-span-all-margin-nested-003-GT-previous.xht
>

It should have been written:
[reftest (old version)]
http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/multicol-span-all-margin-nested-003-GT-previous-ref.xht

> I think both are wrong and that the we need to fix the
> intrinsic/extrinsic sizing spec to do what I wrote above (include column
> gaps in the calculations).


Morten, thank you again for your detailed reply. I appreciate this immensely.

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Wednesday, 21 August 2013 21:24:22 UTC