-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-cascade][cssom] Issues with legacy name alias #4839
Comments
Maybe |
They also aren't properties :-) In Gecko, we parse some webkit gradients but upgrade them to modern syntax when possible. |
@zcorpan An example might be |
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.] |
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. |
The CSS Working Group just discussed
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 |
https://drafts.csswg.org/css-cascade-4/#legacy-name-alias
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
andword-wrap
, neither of which are specified as having a subset of the value space of the new property's syntax.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
The text was updated successfully, but these errors were encountered: