[css-display] Should <display-legacy> values be aliased at parse time? #5575

Loirooriol · 2020-10-02T10:50:16Z

https://drafts.csswg.org/css-display-3/#typedef-display-legacy defines some <display-legacy> values which are equivalent to a <display-outside> || <display-inside> combination:

Short `display`	Full `display`
inline-block	inline flow-root
inline-table	inline table
inline-flex	inline flex
inline-grid	inline grid

And then the spec says

Following the precedence rules of “most backwards-compatible, then shortest”, serialization of equivalent display values uses the “Short display” column.

What seems clear to me is that short and full displays have the same computed value, so we must have

document.body.style.display = "inline flow-root";
getComputedStyle(document.body).display; // "inline-block"

What is less clear to me is whether the aliasing happens only at computed value time, or earlier at parse time:

document.body.style.display = "inline flow-root";
document.body.style.display; // "inline flow-root" or "inline-block" ??

Firefox says "inline-block", Chromium doesn't support the multi-values syntax yet.

While it's common to serialize declared values without optional components when the default value was provided (according to the shortest serialization principle), or with missing optional values that were omitted (against the SSP), or with a normalized order when there are multiple components, it seems less common to completely replace the declared value with another one.

For example, Chromium doesn't do it for contain:

document.body.style.contain = "paint layout";
getComputedStyle(document.body).contain; // "content" in Chromium, "layout paint" in Firefox
document.body.style.contain; // "layout paint" in Chromium & Firefox

The text was updated successfully, but these errors were encountered:

css-meeting-bot · 2021-04-14T16:59:10Z

The CSS Working Group just discussed [css-display] Should <display-legacy> values be aliased at parse time?.

The full IRC log of that discussion

<dael> Topic: [css-display] Should <display-legacy> values be aliased at parse time?
<dael> github: https://github.com//issues/5575
<dael> fantasai: Question of if new display types, we have things line inline-block. Now that we have separate keywords we have inline-display-flow-root is same as inline-block. Defined as same. When you do gCS wanted to return inline-block b/c shortest serialization
<dael> fantasai: Should this be handled at parse time. I think no, author should get what they spec. I think rachelandrew and others have had value in talking as outer and inner display type. If we merge in APIs harder to conceptulaize
<dael> emilio: Much easier to do at parse time for impl. Don't feel super strong. Seems unfortunate display won't compute as specified, but I guess okay
<dael> oriol: While FF does at spec value time, chromium does this for combinations and they are considered to be different. It preserves spec keywords
<dael> florian: emilio, does it make it awkward for impl long term complexity or jsut when you write
<dael> emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math.
<dael> fantasai: Agree with emilio that's a different concern
<dael> oriol: Then it should be different if eq possibility one is legacy css2 and other is new?
<dael> emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done
<dael> emilio: A bit unfortunate that you say inline-flow-root and get back inline-block. But that's what you get in the computed styles
<dael> fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier
<dael> emilio: That's more complicated. new thing to old thing. ideally want other way around
<dael> emilio: So you just worry about inner and outer display value
<dael> fantasai: You want to compute to the new ones but resolved is older?
<dael> emilio: Serialize as the.
<dael> fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat.
<dael> emilio: That does change the behavior of the APIs.
<dael> emilio: We probably don't mind
<fantasai> s/APIs/Houdini APIs/
<dael> emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go
<dael> emilio: Sooner you alias the better
<dael> fantasai: From author PoV system is easier with 2 value keyword. If it's jsut a parse time alias that's helpful but could get a bit confusing. If we can get away with it being 2 keyword values in Houdini gude that's reasonable
<fantasai> s/easier/easier to understand/
<dael> emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved
<dael> emilio: What Gecko impl is computed and resolved are same, serialize legacy
<dael> emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API
<dael> emilio: More work to basically keep the new values in the specified style, return old in computed, return new in Houdini. You're uncomputing what you computed. Fine. A bit more annoying
<dael> fantasai: TabAtkins or rachelandrew?
<dael> emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know
<dael> emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified.
<dael> emilio: Maybe only Houdini exposes new
<dael> TabAtkins: No opinion either way
<dael> astearns: Other opinions?
<dael> rachelandrew: I think as fantasai said from author PoV the two values are understandable and confusing if you get back something other than expected.
<dael> rachelandrew: Prefer we keep the 2 value all the way through if that's possible
<dael> emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same
<dael> iank_: I feel like serialization should go to legacy if they can
<dael> iank_: Worried about the web compat here
<dael> emilio: Right. If you keep as spec it's nice if you're in control. But you prevent adoption. If you use jquery and it expects a return of inline-block and it starts returning inline-flow-root b/c you used it in your style sheet, you can't use it b/c scripts break
<dael> fantasai: That's an arguement to not introduce the display types
<dael> fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script
<dael> emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff.
<dael> emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time
<jensimmons> I'm a bit lost. I'd love for us to compute to the new syntax. Get the world of Authors to move on.
<dael> iank_: I think I'm with emilio. From maintenance PoV and being a previous webdev this would be somewhat concerning. You don't always controls what people are setting display types to.
<dael> astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value?
<dael> iank_: You mean typedOM API?
<dael> astearns: Yep
<dael> emilio: Should be fine
<dael> emilio: Should also be fine to match computed style either way. As long as same value serializes to the same thing it's fine. backwards compat trips. Up to chrome if they want exisintg users of inline-grid to have breaking change
<dael> jensimmons: I understand if there's a compat problem, but I would love to see us for sake of authors compute and return new syntax. I'd love to be able to teach new syntax. Thinking about where will we be 5 years from now. Hvaing to continually teach the old syntax and why? Always a fan of clear the decks and move forward
<dael> jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around
<dael> astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason
<astearns> ack jensimmons
<astearns> ack fantasai
<dael> fantasai: Could decide this is new independent value. Has same behavior but don't compute to each other. We've got 3 possible options
<dael> fantasai: 1) alias at parse time.
<dael> fantasai: 2) 2 independant values with same behavior
<dael> fantasai: 3) do inbetween where some apis return old and some return new if you spec new
<dael> fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew
<miriam> +1
<dael> emilio: I'm okay with saying that.Basically quesiton is how much work does adopting this become. Script authors need to care about both values. That's great for authors of css but not great for authors of script
<dael> iank_: With emilio. I don't htink this is great to go down for script dev that queries style
<dael> astearns: Yeah, if we go with independant values it could slow adoption because not compat
<dael> fantasai: I'm n ot convinced it would be compat problem
<dael> iank_: From what I've seen on gCS and display I think there's a significant chance of people accidentally breaking and not realizing it
<bradk> I’m also leaning towards option 3
<dael> astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM?
<dael> fantasai: Can't do it at parse. Variations on option 3. One would be 2 independent values but have gCS do an extra computation to return old version. We do all kinds of extra lift for gCS.
<dael> astearns: Do people have objections to the version 3?
<dael> fremy: Small question based on minutes. Why can't we do option 3 at parse time? I don't understand. They're exactly the same. inline-block will always be same 2 values in Houdini.
<dael> fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2
<dael> emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM
<dael> fantasai: If you put something in specified style do you get 2 value or 1?
<dael> emilio: Legacy serialiation
<dael> fantasai: .style.display do I get inline-block?
<dael> emilio: You would get inline-block
<dael> fantasai: What's point of having weird in typed OM?
<dael> emilio: It's the one place where we can not go to legacy
<dael> emilio: You have issue of script athors having to care about both values if you don't
<dael> fantasai: But if you do inline-list-item they need to handle. We keep adding display values
<dael> fantasai: We add them al the time. If script doesn't handle new you have to tell the person that my script only handles the old ones. If you're putting limits on script you have to negotiate with user. I don't see why this is a particular problem
<dael> emilio: There's a lot of code that won't update
<dael> fantasai: Sure, and when using don't use new things
<dael> emilio: Problem is, people are not going to be able to use new display values. Moving backwards compat from browser to author. That's fine
<dael> florian: Seems we have same problem in many areas. Script for colors there's may ways to spec red. They all look the same. But we don't serialize LAB space back
<chris> q+
<dael> emilio: Take all hsl and serialize as rgb for that reason
<chris> q-
<astearns> ack chris
<chris> yup. can't unmute
<dael> astearns: Not hearing consensus
<dael> astearns: Does anyone want to try coming up with something we agree on?
<dael> emilio: Won't object if we serialize the new thing, but I don't htink it's best
<TabAtkins> Note that we *only* serialize the older color forms to rgb(). Newer forms, even ones that are absolutely equivalent to rgb(), stay as they are.
<dael> astearns: iank_ you had concerns?
<dael> iank_: I don't think it's the way we should go
<dael> astearns: And others don't think we should be cutting off new display types at serialization time
<dael> astearns: Any way we can get evidence of compat problem?
<dael> fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color
<dael> TabAtkins: We have new color forms that are eq. to rgb but don't serialize. We color turn color into rgb but want to keep in same form. Only older turn into rgb.
<dael> emilio: I have same concern. It's common for script to just parse rgba output
<chris> q+
<dael> iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there
<leaverou_> q+
<dael> iank_: I think less bad b/c breakage is more minor in that case. There's a lot of script htat will check if display is inline-block do something
<dael> fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization
<astearns> ack chris
<dael> chris: Thing about rgba is the spec says regardless of how you spec, rgb or rgba, rgb can get an alpha, but if it's 1 it's thrown out. Only reported if not 1
<astearns> acl ;ea
<dael> chris: Clarifying
<astearns> ack lea
<dael> leaverou_: Comment about scripts that parse rgba, that ship sailed. Not every color can be rgba so scripts need to support other forms. Shouldn't be a concern. With typed OM hopefully devs wouldn't parse colors manually anymore
<chris> Serialization of rgb() or rgba() only reports non-unity alpha
<dael> astearns: I think color discussion is a little far afield. Scripts dealing with display values. I would hope scripts with display values would have an i don't know what this is default.
<chris> Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate
<dael> florian: I think we need data for compat argument. If we show up we can say doing serialization might break things. In theory all sorts of things could break. Do they?
<dael> fremy: We have rule of if can serialize to old we do
<dael> florian: At computed time, yes. Not at specified
<dael> emilio: Isn't that general serialization rule?
<TabAtkins> I suggest this be taken back to the issue for a bit to stew over the options and arguments.
<dael> florian: I don't think so. Am I wrong?
<dael> fantasai: When defined to be equal, we do. If defined to eq. it will serialize to shortest. Debate is do we define to be same at computed or specified value time.
<dael> fantasai: One proposal is they're distinct and different. We do that in other places. We have places in css with same behavior but serialize independent
<dael> iank_: Quick search, jwuery uses this. Likely some cases will break
<dael> astearns: Can you put references in issue iank_ ?
<dael> iank_: Not exaustive. Just a litmus test
<dael> astearns: Nearly out of time. I suggest iank_ puts his in the issue. Others search and add to the issue. We can see what would break and come back at a later date
<dael> astearns: Sound alright?

emilio · 2021-04-14T17:11:43Z

I suspect the code @bfgeek was referring to is this code from jquery. I expect a fair amount of code like that to stop working if we decide to make them separate values with different serializations.

Of course, that's the same kind of thing that would happen if we added a new display type, but it seems a bit unfortunate to enforce everyone to deal with a new name for an old thing :)

Again, I won't object to such thing and I think that even though it's a breaking change for Gecko it's probably an ok change to make, if we go that route, but I'd love to have some feedback from JS frameworks as well if someone has contacts in that space.

astearns · 2021-04-14T17:22:08Z

@stubbornella do you have an opinion on this, or know anyone who could weigh in?

tabatkins · 2021-04-16T14:53:51Z

Of course, that's the same kind of thing that would happen if we added a new display type, but it seems a bit unfortunate to enforce everyone to deal with a new name for an old thing :)

Yeah, as fantasai and others discussed during the call, focusing on "this will break old code that doesn't expect it" is gonna be true for every new feature we ever introduce, and is particularly true for this precise code when we add new display types (such as the half-dozen math-related display types we also decided to add during this call). I'm not sure why we're so pressed about this in particular - it's not changing any existing code, it's just new code written using the new syntax that will cause libraries like this to break (just like they would with display:math).

tabatkins · 2021-08-05T23:50:23Z

Re-reviewing this, @fantasai and I still prefer to leave the new forms as separate values that just act identically. This doesn't change behavior for any code that currently uses a legacy value, and if code breaks with one of the new forms, it'll break with any other new display value, too, so there's not a lot we can do there.

Agenda+ to confirm that this is okay (or decide the opposite). Also need to decide whether computed-value serialization will use the legacy keywords due to the shortest-serialization principle, or if we want to still consider them distinct values that act identically there, too.

css-meeting-bot · 2021-08-18T16:46:00Z

The CSS Working Group just discussed aliasing display-legacy at parse-time, and agreed to the following:

RESOLVED: these values compute to each other and thus serialize as "shortest most backwards-compatible" which is the older keywrods
RESOLVED: serialize specified value of display using keywords specified

The full IRC log of that discussion

<fantasai> Topic: aliasing display-legacy at parse-time
<fantasai> ScribeNick: fantasai
<fantasai> github: https://drafts.csswg.org/css-backgrounds-3/spread-radius
<fantasai> github: https://github.com//issues/5575#issuecomment-893899115
<fantasai> TabAtkins: Awhile ago, Oriol brought up that we have the short display values like inline-block, inline-table, etc.
<fantasai> TabAtkins: after attempt of splitting display property and then re-unifying
<fantasai> TabAtkins: we have two-keyword values
<fantasai> TabAtkins: question was whether these two ways of writing the same value should be canonicalized at parse time or some other time
<fantasai> TabAtkins: Argument for canonicalizing at parse time is that code written before these values were valid, might be expecting inline-foo pattern
<fantasai> TabAtkins: if author writes 'inline flow-root' for some reason, that code wont correctly respond
<fantasai> TabAtkins: counter-argument is that it can be confusing when we return something different from what author wrote, especially for specified values
<fantasai> TabAtkins: and code written in the past will continue to work, just not with the new syntax
<fantasai> TabAtkins: and that code wouldn't work for new display values in any case
<fantasai> TabAtkins: fantasai and I come down on the side of not canonicalizing at specified-value time
<fantasai> TabAtkins: It doesn't create Web-compat issues
<emilio> q+
<fantasai> TabAtkins: and it lets authors work in the syntax they specified
<fantasai> emilio: is proposal to canonicalize at computed value time?
<fantasai> fantasai: Don't we have a requirement for shortest-serialization for getComputedStyle?
<fantasai> TabAtkins: separate question
<fantasai> emilio: It's very easy to check for one and not the other
<fantasai> emilio: I think it's better to canonicalize at parse time
<fantasai> TabAtkins: It sounds like you're saying that canonicalize to happen at some point, and while prefer at specified value but ok if only at computed value?
<fantasai> iank_: Not concerned about Web compat?
<fantasai> emilio: I am, but figure they're accounted for?
<fantasai> iank_: I don't think anyone's done research on this
<fantasai> iank_: If Firefox implements this and it breaks or doesn't break a bunch of sites...
<fantasai> TabAtkins: not canonicalizing can't have Web-compat impact, because legacy code written with inline-block will still return inline-block
<fantasai> TabAtkins: New code written against old libraries would not work maybe, but that's not compat
<fantasai> emilio: Firefox has shipped the new syntax for awhile now
<fantasai> emilio: so could have compat
<fantasai> emilio: I don't think it's super useful not to canonicalize
<fantasai> emilio: useful for authors that write JS code and browsers
<fantasai> astearns: I suspect whether or not we canonicalize at parse time is much less web compat concern than if we do it at computed-value time
<fantasai> astearns: but there's argument of if computed-value is simplified, might be simpler to do it at parse time
<fantasai> iank_: whether we do it at parse time...
<fantasai> TabAtkins: fwiw, I agree that at computed value time they should be canonicalized, because they are in effect the same value, and shortest serialization would require it
<fantasai> iank_: Are we ok with backing out if there's a compat problem?
<fantasai> emilio: this proposed resolution is the behavior of the only existing implementation
<fantasai> TabAtkins: yeah, so this is completely web-compatible if anything can be
<fantasai> fantasai: The existing rule is "shortest most backwards-compatible serialization"
<fantasai> astearns: So want to be clear that they're the same
<fantasai> RESOLVED: these values compute to each other and thus serialize as "shortest most backwards-compatible" which is the older keywrods
<fantasai> TabAtkins: 2 objections to canonicalizing at parse time
<fantasai> TabAtkins: First, specified value should reflect what the author spadi
<fantasai> TabAtkins: if put .style="inline flow-root" should get that back when request it
<fantasai> TabAtkins: Also, canonicalizing back out would make it harder to split back out into two longhands
<fantasai> emilio: I don't see why
<fantasai> fantasai: when teaching CSS, Jen and Rachel have found the split keyword syntax useful for explaining the difference between inner and outer display roles
<jensimmons> yup to useful for teaching. Once they are in every single browser everywhere, I expect developers to start using them exclusively. (AKA, 2027?)
<fantasai> fantasai: If they disappear from the OM as soon as they're inputted, that creates a strong bias against using them, they're not so real anymore
<fantasai> [missed exchange]
<fantasai> emilio: I don't feel super-strongly, can compromise at computed-value time
<fantasai> emilio: I think it's weird one way or the other
<fantasai> emilio: computed value of 'display' is more looked-up than specified value
<fantasai> TabAtkins: in general specified values aren't looked at too much anyway, unless looking at value of style attribute
<fantasai> emilio: I don't see this as super useful, but if fantasai disagrees, it's OK I trust her
<astearns> ack emilio
<fantasai> jensimmons: I haven't been completely following, but +1 to what fantasai said
<fantasai> jensimmons: about the syntax of inner and outer is super useful
<fantasai> jensimmons: teaching now, and later once all browser support it, will likely switch to it
<fantasai> emilio: but if we serialize into old syntax, doesn't seem so useful?
<fantasai> emilio: serializing the old value increases time to adoption, while serilizing the new value which is nicer, but...
<fantasai> astearns: I do agree with Tab's first point, that we do try to keep the serialization of specified values as close to what author inputted as possible
<fantasai> astearns: and sounds like Emilio is OK with that, and didn't hear concerns about having specified vs computed being different
<fantasai> astearns: so proposed resolution is that for specified values we serialize as written
<fantasai> astearns: and for ocmputed value, we canonicalize
<fantasai> emilio: not quite as written, if you write "inline flow"... do you want to serialize to "inline"?
<fantasai> emilio: nevermind
<fantasai> emilio: sounds OK
<fantasai> jensimmons: Not sure what issue is, but if this affects what appears in the computed panel in devtools, idea of browsers saying "I took old value for you and put it into the new style" that would be a good thing
<fantasai> emilio: The computed panel, you can put whatever there. Doesn't affect specified.
<fantasai> jensimmons: I think what happens in parsing engine, nobody knows, doesn't matter to authors
<fantasai> astearns: So can we resolve?
<fantasai> RESOLVED: serialize specified value of display using keywords specified
<bradk> +1

… each other. #5575

…alization" only to computed values. This CL follows resolutions of w3c/csswg-drafts#5575. * ParseDisplayMultipleKeywords() just checks validity of specified keywords, and does not reorder and shorten keywords. * Display::ApplyValue() supports unordered lists. Bug: w3c/csswg-drafts#5575 Bug: mozilla/wg-decisions#622 Bug: 995106 Change-Id: I6c916a8910b32f1d4849c68ac5595f9024bfa0f9

This CL follows resolutions of w3c/csswg-drafts#5575. * ParseDisplayMultipleKeywords() reorders and shortens keywords, but does not change the specified keywords to legacy keywords. * Display::ApplyValue() uses ValidateDisplayKeywords() Bug: w3c/csswg-drafts#5575 Bug: mozilla/wg-decisions#622 Bug: 995106 Change-Id: I6c916a8910b32f1d4849c68ac5595f9024bfa0f9

This CL follows resolutions of w3c/csswg-drafts#5575. * ParseDisplayMultipleKeywords() reorders and shortens keywords, but does not change the specified keywords to legacy keywords. It means - "el.style.display = 'block flow'; el.style.display" returns 'block'. - "el.style.display = 'flow-root inline'; el.style.display" returns 'inline flow-root', not 'inline-block'. * Display::ApplyValue() uses ValidateDisplayKeywords() Bug: w3c/csswg-drafts#5575 Bug: mozilla/wg-decisions#622 Bug: 995106 Change-Id: I6c916a8910b32f1d4849c68ac5595f9024bfa0f9

This CL follows resolutions of w3c/csswg-drafts#5575. * ParseDisplayMultipleKeywords() reorders and shortens keywords, but does not change the specified keywords to legacy keywords. It means - "el.style.display = 'block flow'; el.style.display" returns 'block'. - "el.style.display = 'flow-root inline'; el.style.display" returns 'inline flow-root', not 'inline-block'. * Display::ApplyValue() uses ValidateDisplayKeywords() Bug: w3c/csswg-drafts#5575 Bug: mozilla/wg-decisions#622 Bug: 995106 Change-Id: I6c916a8910b32f1d4849c68ac5595f9024bfa0f9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4493792 Reviewed-by: Oriol Brufau <obrufau@igalia.com> Auto-Submit: Kent Tamura <tkent@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1141725}

…on, a=testonly Automatic update from web-platform-tests css-multiple-display: Update serialization This CL follows resolutions of w3c/csswg-drafts#5575. * ParseDisplayMultipleKeywords() reorders and shortens keywords, but does not change the specified keywords to legacy keywords. It means - "el.style.display = 'block flow'; el.style.display" returns 'block'. - "el.style.display = 'flow-root inline'; el.style.display" returns 'inline flow-root', not 'inline-block'. * Display::ApplyValue() uses ValidateDisplayKeywords() Bug: w3c/csswg-drafts#5575 Bug: mozilla/wg-decisions#622 Bug: 995106 Change-Id: I6c916a8910b32f1d4849c68ac5595f9024bfa0f9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4493792 Reviewed-by: Oriol Brufau <obrufau@igalia.com> Auto-Submit: Kent Tamura <tkent@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1141725} -- wpt-commits: 06fdaf18990326fd1aebf5e52c94cf43eeca5b35 wpt-pr: 39800

Loirooriol added the css-display-3 Current Work label Oct 2, 2020

fantasai added the cssom-1 label Oct 19, 2020

fantasai added the Agenda+ label Apr 1, 2021

astearns added Agenda+ F2F and removed Agenda+ labels Apr 2, 2021

astearns added this to the APAC VF2F-2021-04-08 milestone Apr 2, 2021

astearns added this to Misc in APAC April 8 2021 vFTF Meeting Apr 2, 2021

astearns modified the milestones: APAC VF2F-2021-04-08, EUR VF2F-2021-04-06 Apr 6, 2021

astearns added this to Layout in EUR April 6 2021 vFTF Meeting Apr 6, 2021

astearns removed this from Misc in APAC April 8 2021 vFTF Meeting Apr 6, 2021

atanassov removed this from Layout in EUR April 6 2021 vFTF Meeting Apr 8, 2021

atanassov added this to Tuesday Overflow in APAC April 8 2021 vFTF Meeting Apr 8, 2021

atanassov added Agenda+ and removed Agenda+ F2F labels Apr 9, 2021

astearns removed the Agenda+ label Apr 14, 2021

astearns added this to Layout in EUR July 27 2021 vFTF Meeting Jul 24, 2021

astearns moved this from Layout to Math in EUR July 27 2021 vFTF Meeting Jul 24, 2021

astearns removed this from Math in EUR July 27 2021 vFTF Meeting Jul 24, 2021

astearns removed this from the EUR VF2F-2021-04-06 milestone Jul 24, 2021

tabatkins added the Agenda+ label Aug 5, 2021

css-meeting-bot removed the Agenda+ label Aug 18, 2021

mozilla-apprentice mentioned this issue Aug 18, 2021

[css-display] Should <display-legacy> values be aliased at parse time? mozilla/wg-decisions#622

Open

fantasai added a commit that referenced this issue Aug 24, 2021

[css-display-3] Clarify that 'inline-foo' and 'inline foo' compute to…

48ba2b3

… each other. #5575

fantasai added the Closed Accepted by CSSWG Resolution label Aug 24, 2021

fantasai closed this as completed Aug 24, 2021

chromium-wpt-export-bot mentioned this issue May 2, 2023

css-multiple-display: Update serialization web-platform-tests/wpt#39800

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-display] Should <display-legacy> values be aliased at parse time? #5575

[css-display] Should <display-legacy> values be aliased at parse time? #5575

Loirooriol commented Oct 2, 2020

css-meeting-bot commented Apr 14, 2021

emilio commented Apr 14, 2021 •

edited

astearns commented Apr 14, 2021

tabatkins commented Apr 16, 2021

tabatkins commented Aug 5, 2021

css-meeting-bot commented Aug 18, 2021

[css-display] Should <display-legacy> values be aliased at parse time? #5575

[css-display] Should <display-legacy> values be aliased at parse time? #5575

Comments

Loirooriol commented Oct 2, 2020

css-meeting-bot commented Apr 14, 2021

emilio commented Apr 14, 2021 • edited

astearns commented Apr 14, 2021

tabatkins commented Apr 16, 2021

tabatkins commented Aug 5, 2021

css-meeting-bot commented Aug 18, 2021

emilio commented Apr 14, 2021 •

edited