- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 2 Feb 2017 13:46:07 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Florian Rivoal <florian@rivoal.net>, public-review-announce@w3.org, "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>
On Thu, Feb 2, 2017 at 12:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 2/2/17 2:28 PM, fantasai wrote: >> >> On 02/02/2017 01:18 PM, Boris Zbarsky wrote: >>> >>> OK, so if I have a flex container with two kids, a run-in and a block, >>> do I get one flex item or two flex items and why? And >>> did that require any thought about interactions? >> >> >> You get two flex items, because being in a flex container overrides the >> outer display type of an element: >> https://www.w3.org/TR/css-flexbox-1/#flex-items >> >> In other words, the run-in/inline/block distinction is ignored within a >> flex container. > > > Sure, but my point wasn't whether the behavior is _defined_. It's that > defining it requires thinking about the various cases, and having run-in > makes for more cases to think about. Not really. The Flexbox text was written without any consideration of run-ins. It nevertheless handles run-ins correctly (they get blockified and become flex items). Grid should work the same way, as will any future layout modes we define. (v1 of Custom Layout blockifies children in the same way, or at least is meant to; it's been too long since I reviewed that part of the spec.) ~TJ
Received on Thursday, 2 February 2017 21:47:03 UTC