W3C home > Mailing lists > Public > www-style@w3.org > December 2012

RE: [css3-flexbox] Bad result in flex algorithm when combining stretch, and elements with an aspect ratio

From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Date: Fri, 7 Dec 2012 01:09:47 +0000
To: "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>, Alex Mogilevsky <alexmog@microsoft.com>
Message-ID: <9A57384B9CE9AE4F9C01F3BB5C3D88440173D176@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
> -----Original Message-----
> From: Kang-Hao (Kenny) Lu [mailto:kanghaol@oupeng.com]
> Sent: Tuesday, December 4, 2012 1:03 AM
> To: Tab Atkins Jr.
> (12/12/04 4:27), Tab Atkins Jr. wrote:
> >> I've gotten private feedback from Ojan & Tony that they're fine with
> >> these additions, and I think this matches IE's behavior.  If I don't
> >> get any objections from one of the other browsers, I'll put this into
> >> the spec in a few days.
> Are there test cases showing that IE is indeed doing this? My test[1]
> unexpectedly shows the contrary in IE10 (and so I can't do further testing
> with my comments below). Chrome and Opera 12.10 give stretched images,
> as expected.

You're right that we currently don't respect the intrinsic ratio for the test case you have below [1]. At the same time the proposed changes to the spec (http://dvcs.w3.org/hg/csswg/diff/284a967553ae/css3-flexbox/Overview.src.html) will mean that none of the current implementations are implementing it either. As a feature these changes look quite reasonable and are very similar to setting height and expecting the main axis (width in this particular case) to be defined by the intrinsic ratio (see case [2]).

After reviewing the proposed changes above, we think that the new additions are reasonable and are fine with them.

One clarification to this thread. When I originally discussed this with Tab the scenario I described involved multiline flex and items that have intrinsic ratio. What I pointed out was the difference between our implementation and the spec definition (chrome's implementation seems to follow that) in how and when the line breaks are evaluated. When flex items get stretched to the line cross size they might end up changing the line break if their main axis size changed as a consequence of that. Both IE and Opera will currently re-evaluate the line break thus clear the following items to the next line (see case [3]), while Chrome will actually overlap the following items. Further, it looks like Opera has more heuristics for this scenario and they will disregard the size change if it happens to push the item itself to the next line.

For this new problem (the multiline case) we are not sure what the best approach is. On one hand we can end up with overlapping flex items, thus content might be hidden. On the other hand we might end up with items being pushed and not resized properly (current IE behavior). 

Note that compared to regular text line layout, images can't get into this loop since they can't take a height dependency on the line itself. Thus line breaks can be determined in one dimension only. 
> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1981

[2] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2002

[3] http://jsfiddle.net/69qda/4/ 

Received on Friday, 7 December 2012 01:10:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:06 UTC