Intent to ship: multi-keyword values on the CSS 'display' property

[Mats Palmgren]

Summary:
Add support for multi-keyword values on the CSS 'display' property.
The spec splits this property into three parts: an outside part,
an inside part, and a list-item part so the author can specify them
separately. This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).
So, this bug just adds a bunch of synonyms for exist values we
already support, so we can now write "block flow list-item" or
"block list-item" etc instead of just "list-item". Keywords can
be given in arbitrary order, so there are now a lot of valid
permutations for the same computed value. The values are
serialized to their shortest form as usual though.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038294

Standard: https://drafts.csswg.org/css-display/#the-display-properties

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: No change

Tests: WPT and other tests were added.

Other browsers: Other UAs don't support this yet, AFAIK.


/Mats

[Mats Palmgren]

[Boris Zbarsky]

On 8/14/19 12:37 PM, Mats Palmgren wrote:
> This first patch set adds support for the new syntax
> only, but no new box types (I'll add those separately in a bit).

In general, it seems like we should think about how to integrate this
stuff into layout in a better way than anonymous boxes everywhere. In
particular, we may want to consider changing nsIFrame such that we have
it point to a "how I look to my parent" class and a "how I manage my
kids or paint myself" class and be able to mix and match those. That's
out of scope for this intent, but if we plan to start adding various
implementations of multiple keywords for display this seems like it
would be the way to go about it...

> Other browsers: Other UAs don't support this yet, AFAIK.

Do they plan to?

-Boris

[Mats Palmgren]

On 8/14/19 6:52 PM, Boris Zbarsky wrote:
> On 8/14/19 12:37 PM, Mats Palmgren wrote:
>> This first patch set adds support for the new syntax
>> only, but no new box types (I'll add those separately in a bit).
>
> In general, it seems like we should think about how to integrate this
> stuff into layout in a better way than anonymous boxes everywhere.  In
> particular, we may want to consider changing nsIFrame such that we have it
> point to a "how I look to my parent" class and a "how I manage my kids or
> paint myself" class and be able to mix and match those.

I agree, but splitting up the 'display' property into three separate
keywords doesn't imply we'll implement them using anonymous boxes in
more cases than if it's just one keyword. Your point is well taken but
it's an independent issue.

I'm guessing you're thinking of the implementation of 'block ruby',
which indeed does introduce a new anonymous box (it's a block box with
anonymous ruby box inside it).
This is mandated by the Ruby spec though:
"If an element has an inner display type of ruby and an outer display type
other than inline, then it generates two boxes: a principal box of the
required outer display type type, and an inline-level ruby container. All
properties specified on the element apply to the principal box (and if
inheritable, inherit to the ruby container box)."
https://drafts.csswg.org/css-ruby-1/#block-ruby

(It makes sense to me to use two boxes in this case. I'm happy to
continue discuss that off-list I you want.)

(There are no anonymous boxes associated with any of the list-item values.)

>> Other browsers: Other UAs don't support this yet, AFAIK.
>
> Do they plan to?

I don't know what their plans are. I haven't seen any public
announcements one way or another.


/Mats

[一丝]

Is there a plan to implement multi-valued table | flex | grid? E.g display: inline flex.

[Emilio Cobos Álvarez]

On 8/22/19 11:28 AM, 一丝 wrote:
> Is there a plan to implement multi-valued table | flex | grid? E.g
> display: inline flex.

That should work, afaict.

[Boris Zbarsky]

On 8/19/19 3:42 PM, Mats Palmgren wrote:
> Your point is well taken but it's an independent issue.

Sure. I'm just saying that I suspect some of the combinations may be
hard to implement using anon boxes, depending on what combinations are
allowed.

For example, can one have a thing which is "table-cell" on the outside
and "flex" on the inside, per spec?

> I don't know what their plans are.  I haven't seen any public
> announcements one way or another.

It's worth trying to find out, and in particular to find out whether
what we plan to ship is compatible with what they plan to ship.

-Boris

[Mats Palmgren]

On 8/26/19 4:42 PM, Boris Zbarsky wrote:
> On 8/19/19 3:42 PM, Mats Palmgren wrote:
> Sure.  I'm just saying that I suspect some of the combinations may be hard
> to implement using anon boxes, depending on what combinations are allowed.
>
> For example, can one have a thing which is "table-cell" on the outside and
> "flex" on the inside, per spec?

No, 'table-cell' is currently a <display-internal> keyword and those
can't be combined with other keywords at all. [1]

However, I'm proposing in [2] that 'table-cell'/'table-caption'
should instead be <display-outside> keywords [3], which would allow
'display:table-cell flex' etc.

I've written proof-of-concept code to implement that and it was
fairly straight-forward now that we support multi-keyword values
in general. I didn't see any signs of additional complications
regarding anon boxes from this. (To be concrete, removing the inner
anon box we currently have for table cells wouldn't become harder,
nor easier, by any of these changes.)

(I'll add a disclaimer for 'run-in' though. It's not implemented
by anyone yet so it's hard to speculate about. I'll also add that
I (and others) have doubts about it...)

> It's worth trying to find out, and in particular to find out whether what
> we plan to ship is compatible with what they plan to ship.

Well, the CSS spec is public and being actively discussed in various
github issues / www-style. I would expect them to file a spec issue
if they have objections or intend to implement something different.

/Mats

[1]
https://drafts.csswg.org/css-display-3/#the-display-properties

[2]
https://github.com/w3c/csswg-drafts/issues/3940

[3]
https://drafts.csswg.org/css-display-3/#typedef-display-outside