- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Sat, 9 May 2015 16:13:49 +0000
- To: Gérard Talbot <www-style@gtalbot.org>
- CC: Elika Etemad <fantasai.lists@inkedblade.net>, W3C www-style mailing list <www-style@w3.org>
On May 9, 2015, at 13:48, Gérard Talbot <www-style@gtalbot.org> wrote: > > Hello, > > While trying to create a few tests based on this example > > http://dev.w3.org/csswg/css-writing-modes-3/#example-30ac251e > > http://dev.w3.org/csswg/css-writing-modes-3/orthogonal.svg > > I stumbled on an unusual rendering, at least, unexpected. > > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/Orthogonal-flow-Example14-2.xht > > IE11, Chrome 44 and Firefox 40 render that Orthogonal-flow-Example14-2 test exactly the same way... which is a bit worrysome… > > That is, div#next-sibling is rendered before div#next-sibling which seems, at least to me, unexpected and counter-intuitive. I think this rendering is wrong. I would expect p#second-parg to be laid out first and before div#next-sibling is rendered. > > Comments are welcomed. Isn’t it because you have “height:200px” to horiz-tb-containing-block? Consider a horizontal case[1]. Because the green box has “width:200px”, the pink box shrink to 200px (not 200px - the width of the yellow box), and thus the pink box does not fit because of the yellow box and it wraps to the next line Vertical flow can’t wrap, so it overflows. The result looks natural to me. I have to admit that I don’t understand all written in the spec, but from which part of the spec did you think this should work? [1] http://jsbin.com/cexaqu/edit?html,output /koji
Received on Saturday, 9 May 2015 16:14:21 UTC