Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On Thu, Feb 2, 2017 at 12:46 PM, Boris Zbarsky 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
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
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. -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 02/02/2017 01:18 PM, Boris Zbarsky wrote: On 2/1/17 6:07 PM, fantasai wrote: Wrt this particular issue, run-ins only run into other blocks; they do not exist in or affect layout modes other than block-and-inline. 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. ~fantasai
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 2/1/17 6:07 PM, fantasai wrote: Wrt this particular issue, run-ins only run into other blocks; they do not exist in or affect layout modes other than block-and-inline. 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? -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 01/26/2017 12:10 AM, Boris Zbarsky wrote: On 1/25/17 10:48 PM, Florian Rivoal wrote: Is it a general argument that adding more things to the platform always makes it harder down the road to add more things due to having to figure out more interactions It's not a general argument in this case. It's a specific argument. For example, adding any new display type has to consider how it interacts with run-in. Adding anything that rearranges things in terms of layout (e.g. shadow DOM, flexbox, grid, etc) has to consider how it interacts with run-in and whether the result makes any sense. Wrt this particular issue, run-ins only run into other blocks; they do not exist in or affect layout modes other than block-and-inline. ~fantasai
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 1/25/17 10:48 PM, Florian Rivoal wrote: Is it a general argument that adding more things to the platform always makes it harder down the road to add more things due to having to figure out more interactions It's not a general argument in this case. It's a specific argument. For example, adding any new display type has to consider how it interacts with run-in. Adding anything that rearranges things in terms of layout (e.g. shadow DOM, flexbox, grid, etc) has to consider how it interacts with run-in and whether the result makes any sense. Adding any structural pseudo-elements, have to consider run-in (note that the run-in spec already has to specify interactions with ::marker and ::before). That's on the specification side. On the implementation side, run-in makes all sorts of element insertion/removal either slow or complicated or both, because you have to deal with it affecting the run-in situation. Who knows. Some of us are new enough to this discussion that we may not know of all the arguments that had been presented against it in the past. Anyway, what I suggest is writing _very_ thorough run-in tests, including all the dynamic mutation cases. Something akin to what you see in https://bugzilla.mozilla.org/attachment.cgi?id=421975 but targeting the current spec. I should note that at the point when I wrote those tests, they mostly failed in all implementations; a bunch of them crashed in various implementations. I'd hope the new text is at least easier to implement sanely, but I'm not holding my breath too hard on it... -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
> On Jan 26, 2017, at 12:23, Boris Zbarsky wrote: > > It will complicate attempts to add other, much higher value, features to > CSS, again both in terms of specification and implementation. Could you elaborate on that? Is it a general argument that adding more things to the platform always makes it harder down the road to add more things due to having to figure out more interactions, or is there something specific with run-in that you think will get in the way? What kind of thing do you expect it to get in the way of? > And again, I don't expect this mail to actually change anything. But I felt > like I had to try one last time... Who knows. Some of us are new enough to this discussion that we may not know of all the arguments that had been presented against it in the past. —Florian
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 1/25/17 8:14 PM, fantasai wrote: * a 'run-in' layout model slightly less insane than the one proposed in CSS2.0 I like the truth in advertising there. ;) I'd just like to reiterate my (longstanding, so unlikely to sway anyone) opinion that run-in, even in this "less insane" incarnation, introduces an amount of complexity to both specification and implementation that is wholly disproportionate to its value as a feature. It will complicate attempts to add other, much higher value, features to CSS, again both in terms of specification and implementation. I think we would be better off not adding this feature. -Boris P.S. I don't see much point filing this as a github issue, since this really isn't the sort of comment that lends itself to discussion on github. And again, I don't expect this mail to actually change anything. But I felt like I had to try one last time...
