- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Oct 2020 00:01:54 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-cascade][cssom] Issues with legacy name alias<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4839#issuecomment-700430018<br> <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?<br> <dael> fantasai: Mainly use these for WK prefix but a couple others we did an alias<br> <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?<br> <TabAtkins> q+<br> <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.<br> <miriam> +1<br> <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<br> <dael> astearns: Arguments against keeping same?<br> <dael> florian: Have a weak argument<br> <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<br> <astearns> ack TabAtkins<br> <jensimmons> q+<br> <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<br> <dael> smfr: We might need exceptions for properties where we have divergence<br> <dael> fantasai: If substanitally different we use a different mech<br> <dael> florian: If we find one we can always call it out<br> <astearns> ack jensimmons<br> <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.<br> <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<br> <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.<br> <dael> astearns: Prop: For aliased properties both sides of the alias get new values as defined in general rule<br> <dael> RESOLVED: For aliased properties both sides of the alias get new values as defined as a general rule<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4839#issuecomment-705254644 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 October 2020 00:01:57 UTC