Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3

[Tab Atkins Jr.]

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

[Boris Zbarsky]

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

[fantasai]

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

[Boris Zbarsky]

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

[fantasai]

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

[Boris Zbarsky]

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

[Florian Rivoal]

> 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

[Boris Zbarsky]

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...