Description
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