- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Thu, 17 Apr 2014 15:50:21 +0000
- To: John Kreitlow <john.kreitlow@gmail.com>, Christian Biesinger <cbiesinger@google.com>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, Daniel Holbert <dholbert@mozilla.com>, "www-style@w3.org" <www-style@w3.org>
> I made this codepen to outline the case: http://codepen.io/radium-v/pen/ropFz > The example works as I'd expect in Chrome 34, IE11, and Safari 7 - but it unfortunately breaks in Firefox 28 (Daniel suggests the opposite though, that FF > exhibits the correct behavior while the other browsers fail to match the spec). > It seems to me that the paragraph from the spec is intended for single-line flex containers. It doesn't take into account how multi-line containers > should behave, especially their dimensions aren't explicitly defined. > There's some more detail regarding this section of the spec found here http://lists.w3.org/Archives/Public/www-style/2013Mar/0688.html > I'm in favor of changing things here - it shouldn't be assumed that a flex container is more likely to be given an explicit height, since it's not assumed in most other cases. Those are all valid points, but we would prefer Grid and Flex being consistent with one another and resolving these values in the same manner. Because of that, we are in favor of IE and Chrome updating their implementations to match Gecko and the spec. I do think you bring up an interesting use case and would love to see us address it since authors will undoubtedly hit it. I do like Tabs idea of a property because then there is no confusion to the author as to what they are selecting to resolve against. I also think that resolving padding-top against the width is similarly confusing to authors and we shouldn’t repeat that (I understand why they chose that for flows) but for a long time I always assumed that it _WAS_ resolved against the height. Greg
Received on Thursday, 17 April 2014 15:50:49 UTC