You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the old property has a distinct syntax from the new property, the two names are aliased using the shorthand mechanism. These shorthands are defined to be legacy shorthands, and their use is deprecated. They otherwise behave exactly as regular shorthands, except that the CSSOM will not use them when serializing declarations.
i.e. the shorthand sets the longhand to a special value that cannot be represented by its grammar, so the longhand serializes as empty string, but the shorthand can serialize the value. Somewhat analogous to when setting a shorthand to a variable.
This is what browsers do:
Firefox ignores the spec and accepts background-clip: text as valid. This avoids serialization problems:
WebKit doesn't implement -webkit-background-clip as a shorthand. Instead, it's implemented as an independent longhand that shares a computed style with background-clip (somewhat like physical and logical properties also share a computed value). Additionally, it accepts background-clip: text as valid:
The correct answer here is "mu" - if the legacy shorthand has a value not present in the real longhands, then it's a browser-specific extension. If we want it to not be that, we have to define what that value means in the real property. (Even if the answer is "nothing, this is just a technically-valid legacy keyword that does nothing".)
I picked an example which is not a browser-specific extension since supporting -webkit-background-clip: text is required by the Compatibility spec. And its meaning is
Indicates that the background image should clip to the foreground text
https://drafts.csswg.org/css-cascade-4/#legacy-shorthand
The problem is that some of these legacy shorthands can accept some values which have no equivalent in the standard property. For example, https://drafts.csswg.org/css-backgrounds-3/#propdef-background-clip
But then https://compat.spec.whatwg.org/#the-webkit-background-clip-property defines this legacy shorthand:
So it's not clear what happens if you set
-webkit-background-clip: text
. I would expect something like:i.e. the shorthand sets the longhand to a special value that cannot be represented by its grammar, so the longhand serializes as empty string, but the shorthand can serialize the value. Somewhat analogous to when setting a shorthand to a variable.
This is what browsers do:
Firefox ignores the spec and accepts
background-clip: text
as valid. This avoids serialization problems:Blink serializes
background-clip
as"text"
, but this seems very wrong becausebackground-clip: text
is considered invalid!WebKit doesn't implement
-webkit-background-clip
as a shorthand. Instead, it's implemented as an independent longhand that shares a computed style withbackground-clip
(somewhat like physical and logical properties also share a computed value). Additionally, it acceptsbackground-clip: text
as valid:Other properties may have other behaviors.
The text was updated successfully, but these errors were encountered: