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

[fantasai]

The CSS WG has published an updated Working Draft of the CSS Display Module Level 3:

https://www.w3.org/TR/css-display-3/

This module describes how the CSS formatting box tree is generated from the
document element tree and defines the display property that controls it.
Additions since CSS2 include
* a 'flow-root' value to create a block formatting context root (BFC)
* a 'contents' value to discard the element's box but keep its children
* inline list items
* a 'run-in' layout model slightly less insane than the one proposed in CSS2.0

Significant changes are listed at:

https://www.w3.org/TR/2017/WD-css-display-3-20170125/#changes

We anticipate this being the last draft before the transition to CR,
therefore this is the "last call" for comments.

Please review the draft, and send any comments to the CSSWG mailing list,
<www-***@w3.org>, prefixed with [css-display] (as I did on this message)
or (preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

[Boris Zbarsky]

Post by fantasai
* 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...

[Florian Rivoal]

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

[Boris Zbarsky]

Post by Florian Rivoal
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.

Post by Florian Rivoal
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

[fantasai]

Post by Boris Zbarsky

Post by Florian Rivoal
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

[Boris Zbarsky]

Post by fantasai
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

[fantasai]

Post by fantasai
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

[Boris Zbarsky]

Post by fantasai

Post by Boris Zbarsky
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
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

[Tab Atkins Jr.]

Post by Boris Zbarsky

Post by fantasai

Post by Boris Zbarsky
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
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