Re: [css3-multicol] Nested multicolumn elements rendering

Le Jeu 8 août 2013 5:54, Morten Stenshorne a écrit :
> "Gérard Talbot" <www-style@gtalbot.org> writes:
>
>> Hello,
>>
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/multicol-height-block-child-001-GT.xht
>>
>> I'm trying to better understand nested multi-columns. Can anyone please
>> explain to me what would be the expected layout of this test ? And give
>> me some hints about the logic of such rendering.
>
> See http://www.w3.org/TR/css3-multicol/#the-multi-column-model and what
> it has to say about rows. You'll end up creating one row in the inner
> multicol for each outer column (in your test, all the text actually fits
> in the first outer column, but the inner multicol itself is taller, so
> it takes up space in the second outer column as well; whether there is a
> content-less row there or just no content is probably unknown and
> irrelevant). The spec says "paginated" and "page" all the time, but it
> should apply just as much to outer multicol containers, and even
> regions.
>
> Example:
>
> <div style="columns:2; column-fill:auto; column-rule:thin solid;
> height:4em; line-height:1em;">
>   <div style="columns:2;">
>     aaa<br>
>     bbb<br>
>     ccc<br>
>     ddd<br>
>     eee<br>
>     fff<br>
>     ggg<br>
>     hhh<br>
>     iii<br>
>     jjj<br>
>     kkk<br>
>     lll<br>
>   </div>
> </div>
>
> This should render like this:
>
> aaa      eee    | iii      kkk
> bbb      fff    | jjj      lll
> ccc      ggg    |
> ddd      hhh    |
>

Morten,

I've created your test (I have set the inner multi-column to 'column-fill:
auto' to make it a bit easier to figure out and added colored borders) and
uploaded here:

http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/Nested-multicol-M-Stenshorne.xht


>> IE10 and Opera 12.16 render it identically: only the 3 trios of
>> "m" are rendered. The 3 trios of "z" are unexpectedly clipped.
>>
>> Firefox 23 and Prince9
>> http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/multicol-height-block-child-001-GT.pdf
>> render it identically.
>>
>> Chrome 28.0.1500.95 renders the test differently from all 4 others.
>
> To answer your comment in the file:
>
>> <!-- why do we see only the 3 lines of mmm in Opera 12.16 and IE10 ? -->
>
> Because the inner multicol is set to be exactly as wide as the outer
> multicol. Since there are two columns, the right half of the inner
> multicol will end up outside the outer column boxes' bounds.

Yes.

> The last
> three words will end up in a second inner column (still in the first
> outer column), which will get clipped, since there are two outer
> columns.

Ok. Thanks. I think I understand now.

> There are two outer columns because the inner multicol has a
> height of 8em, which there isn't room for in the first outer column,
> since there's already some "aaa" content there.
>
> So IE10 and Opera (Presto) do it right.
>
> Gecko decides to move the entire inner multicol to a new outer
> column. That seems unnecessary, although in this particular case it does
> make more content visible. :) Oh, it actually appears that Gecko doesn't
> allow/support fragmentation of multicol containers at all.

You're right. Firefox 23 does not support fragmentation of multicol
containers; we can notice this in

http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/Nested-multicol-M-Stenshorne.xht

>
> The WebKit/Blink implementation of nested multicol is basically missing
> (I'm working on it), and what you see is really just the effect of NOT
> supporting nested multicol.
>
>> I've added vendor-prefixes and web-embedded Ahem font to make the test
>> easier to check in different browsers.
>
> Ah, an opportunity for my daily Ahem rant... :)
>
> Ahem makes text unreadable! (well, duh)

This is in fact a good comment. I think we would be ready to create a
customized-for-CSS-test-purposes font where glyphs (of latin alphabet: a,
b, c, etc.) would be recognizable and where, just like Ahem font, the
descender space, ascender space, em dimensions, etc.. would be entirely
reliable and entirely predictable.

The Ahem font would still be useful in a bunch of cases. But we would have
more than 1 font for accurate testing of inline content.


> Rather than using Ahem in the test, you could set line-height and only
> use explicit line breaks, and not provide any automatic line break
> opportunities (avoid white-space altogether, or set
> white-space:nowrap). Then it would be easier see the "mmm"s and so
> on. :)

I'll take into consideration your idea for future tests here.
This is how most of the Opera tests have been doing.

Morten, thank you again for your extremely useful feedback.

Gérard

>
> --
> ---- Morten Stenshorne, developer, Opera Software ASA ----
> ------------------ http://www.opera.com/ -----------------
>


-- 
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 Thursday, 8 August 2013 18:23:07 UTC