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

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
0
Mats
8/14/2019 4:37:48 PM
mozilla.dev.platform 6586 articles. 0 followers. Post Follow

7 Replies
52 Views

Similar Articles

[PageSpeed] 24

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
0
Mats
8/14/2019 4:37:48 PM
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
0
Boris
8/14/2019 4:52:56 PM
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
0
Mats
8/19/2019 7:42:26 PM
Is there a plan to implement multi-valued table | flex | grid? E.g display: inline flex.
0
UTF
8/22/2019 9:28:50 AM
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.
0
UTF
8/22/2019 9:49:44 AM
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
0
Boris
8/26/2019 2:42:06 PM
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
0
Mats
8/26/2019 7:30:34 PM
Reply: