[css-display] Should values be aliased at parse time?

[Loirooriol]

https://drafts.csswg.org/css-display-3/#typedef-display-legacy defines some values which are equivalent to a || 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

[css-meeting-bot]

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

The full IRC log of that discussion

Topic: [css-display] Should values be aliased at parse time?
github: https://github.com//issues/5575
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
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
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
oriol: While FF does at spec value time, chromium does this for combinations and they are considered to be different. It preserves spec keywords
florian: emilio, does it make it awkward for impl long term complexity or jsut when you write
emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math.
fantasai: Agree with emilio that's a different concern
oriol: Then it should be different if eq possibility one is legacy css2 and other is new?
emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done
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
fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier
emilio: That's more complicated. new thing to old thing. ideally want other way around
emilio: So you just worry about inner and outer display value
fantasai: You want to compute to the new ones but resolved is older?
emilio: Serialize as the.
fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat.
emilio: That does change the behavior of the APIs.
emilio: We probably don't mind
s/APIs/Houdini APIs/
emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go
emilio: Sooner you alias the better
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
s/easier/easier to understand/
emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved
emilio: What Gecko impl is computed and resolved are same, serialize legacy
emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API
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
fantasai: TabAtkins or rachelandrew?
emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know
emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified.
emilio: Maybe only Houdini exposes new
TabAtkins: No opinion either way
astearns: Other opinions?
rachelandrew: I think as fantasai said from author PoV the two values are understandable and confusing if you get back something other than expected.
rachelandrew: Prefer we keep the 2 value all the way through if that's possible
emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same
iank_: I feel like serialization should go to legacy if they can
iank_: Worried about the web compat here
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
fantasai: That's an arguement to not introduce the display types
fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script
emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff.
emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time
I'm a bit lost. I'd love for us to compute to the new syntax. Get the world of Authors to move on.
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.
astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value?
iank_: You mean typedOM API?
astearns: Yep
emilio: Should be fine
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
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
jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around
astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason
ack jensimmons
ack fantasai
fantasai: Could decide this is new independent value. Has same behavior but don't compute to each other. We've got 3 possible options
fantasai: 1) alias at parse time.
fantasai: 2) 2 independant values with same behavior
fantasai: 3) do inbetween where some apis return old and some return new if you spec new
fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew
+1
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
iank_: With emilio. I don't htink this is great to go down for script dev that queries style
astearns: Yeah, if we go with independant values it could slow adoption because not compat
fantasai: I'm n ot convinced it would be compat problem
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
I’m also leaning towards option 3
astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM?
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.
astearns: Do people have objections to the version 3?
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.
fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2
emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM
fantasai: If you put something in specified style do you get 2 value or 1?
emilio: Legacy serialiation
fantasai: .style.display do I get inline-block?
emilio: You would get inline-block
fantasai: What's point of having weird in typed OM?
emilio: It's the one place where we can not go to legacy
emilio: You have issue of script athors having to care about both values if you don't
fantasai: But if you do inline-list-item they need to handle. We keep adding display values
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
emilio: There's a lot of code that won't update
fantasai: Sure, and when using don't use new things
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
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
q+
emilio: Take all hsl and serialize as rgb for that reason
q-
ack chris
yup. can't unmute
astearns: Not hearing consensus
astearns: Does anyone want to try coming up with something we agree on?
emilio: Won't object if we serialize the new thing, but I don't htink it's best
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.
astearns: iank_ you had concerns?
iank_: I don't think it's the way we should go
astearns: And others don't think we should be cutting off new display types at serialization time
astearns: Any way we can get evidence of compat problem?
fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color
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.
emilio: I have same concern. It's common for script to just parse rgba output
q+
iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there
q+
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
fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization
ack chris
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
acl ;ea
chris: Clarifying
ack lea
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
Serialization of rgb() or rgba() only reports non-unity alpha
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.
Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate
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?
fremy: We have rule of if can serialize to old we do
florian: At computed time, yes. Not at specified
emilio: Isn't that general serialization rule?
I suggest this be taken back to the issue for a bit to stew over the options and arguments.
florian: I don't think so. Am I wrong?
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.
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
iank_: Quick search, jwuery uses this. Likely some cases will break
astearns: Can you put references in issue iank_ ?
iank_: Not exaustive. Just a litmus test
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
astearns: Sound alright?

[emilio]

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]

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

[tabatkins]

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]

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]

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

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