[css-cascade][cssom] Issues with legacy name alias

[zcorpan]

https://drafts.csswg.org/css-cascade-4/#legacy-name-alias

legacy name aliases
When the old property’s syntax is identical to or a subset of the value space of the new property’s syntax, the two names are aliased with an operation on par with case-mapping: at parse time, the old property is converted into the new property. This conversion also applies in the CSSOM, both for string arguments and property accessors: requests for the old property name transparently transfer to the new property name instead.

Which property, if any, uses a subset of the value space?

As far as I can tell, the only uses of the "legacy name alias" concept are -webkit-appearance and word-wrap , neither of which are specified as having a subset of the value space of the new property's syntax.

$ git grep "legacy name alias"
css-cascade-4/Overview.bs:              <dt><dfn lt="legacy name alias">legacy name aliases</dfn>
css-cascade-4/Overview.bs:                              <css>old-name</css> is a <a>legacy name alias</a> for <css>new-name</css>,
css-text-3/Overview.bs:    <p>For legacy reasons, UAs must treat 'word-wrap' as an [=legacy name alias=]
css-ui-4/Overview.bs:as a [=legacy name alias=] of 'appearance'.

https://compat.spec.whatwg.org/ doesn't reference this concept, but it probably should. -webkit-linear-gradient() and friends aren't simple aliases, but also aren't subsets. How is this handled in serialization?

The definition of legacy name alias also monkey patches CSSOM. I think it should be defined in the relevant algorithms in CSSOM, like https://drafts.csswg.org/cssom-1/#dom-cssstyledeclaration-getpropertyvalue and https://drafts.csswg.org/cssom-1/#dom-cssstyledeclaration-setproperty

cc @emilio @tkent-google @tabatkins @miketaylr

[miketaylr]

Maybe -webkit-background-size is an example that uses a subset of unprefixed background-size's value space?

whatwg/compat#28

[emilio]

https://compat.spec.whatwg.org/ doesn't reference this concept, but it probably should. -webkit-linear-gradient() and friends aren't simple aliases, but also aren't subsets. How is this handled in serialization?

They also aren't properties :-)

In Gecko, we parse some webkit gradients but upgrade them to modern syntax when possible.

[fantasai]

@zcorpan An example might be word-wrap, which only accepted normal and break-word; we added an anywhere value. But didn't define word-wrap to not accept the new value, which is an interesting detail we forgot to consider.

[fantasai]

Agenda+ to ask the WG whether legacy name alias properties should be "upgraded" to accept new syntaxes added to their aliased property (being strictly a name alias), or whether they should be syntactically frozen (have stricter restrictions on value space).

[Also to assign the CSSOM edits to someone.]

[zcorpan]

I think it's simpler to let aliases have exactly the same value space. That we don't want people to use the old property name isn't a good reason to add complexity, imo.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade][cssom] Issues with legacy name alias, and agreed to the following:

• RESOLVED: For aliased properties both sides of the alias get new values as defined as a general rule

The full IRC log of that discussion

<dael> Topic: [css-cascade][cssom] Issues with legacy name alias
<dael> github: https://github.com//issues/4839#issuecomment-700430018
<dael> fantasai: Issue is that we have legacy name aliases. Just name changes. Question raised about if you add new values to the new property does old property get those new values?
<dael> fantasai: Mainly use these for WK prefix but a couple others we did an alias
<dael> fantasai: Question to WG is do we define the value space is idential or freeze the value-space to what's needed for compat?
<TabAtkins> q+
<heycam> +1 to keeping the value spaces the same. don't think there's much benefit to preventing the new values from being visible in the old property name.
<miriam> +1
<dael> TabAtkins: I agree in general with zcorpan where trying to freeze makes it separate properties so sounds like effort with no reason. Keep strict alias
<dael> astearns: Arguments against keeping same?
<dael> florian: Have a weak argument
<dael> smfr: Sort of depends on compat. I'm sure in WK there are both impl. If we decide a prefix which is aliased and it should be forven there's compat risk because prefix doesn't support new. Need compat research
<astearns> ack TabAtkins
<jensimmons> q+
<dael> florian: If we decide this and freeze no now risk. Risk is we fail to encentize migration. Doesn't feel strong for legacy names where we felt needed to be in spec. For ones we want to fade away useful to freeze but those we've enshrined in the spec we've decided we have to have and might as well keep
<dael> smfr: We might need exceptions for properties where we have divergence
<dael> fantasai: If substanitally different we use a different mech
<dael> florian: If we find one we can always call it out
<astearns> ack jensimmons
<dael> jensimmons: Responding to florian I don't think it's important to motivate authours b/c they are motivated. vendor prefix are gone in their minds and the ones out there are on un-maintained sites.
<dael> jensimmons: More improtant I don't know if in every case old code 7 years ago can alias to new updated spec b/c too much has changed
<dael> florian: I don't htink this is should we alias everything. But where we have aliased does a new value become available on legacy. I thik the answer is yes.
<dael> astearns: Prop: For aliased properties both sides of the alias get new values as defined in general rule
<dael> RESOLVED: For aliased properties both sides of the alias get new values as defined as a general rule