Intent to Ship: offset-path; Deprecate and Remove: motion-path

[Eric]

Contact emails

ericwi...@chromium.org, sh...@chromium.org

Spec

https://drafts.fxtf.org/motion-1/

TAG Review https://github.com/w3ctag/spec-reviews/issues/66

Summary

The CSS Motion Path properties (already shipped by Chrome) have recently been renamed:

motion-path becomes offset-path

motion-offset becomes offset-distance

motion-rotation becomes offset-rotation

The shorthand property has also been renamed:

motion becomes offset

This occurred when the CSS Round Display functionality was merged into the CSS Motion Path spec.

We propose to rename the properties to offset-path, offset-distance and offset-rotation.  offset will be implemented behind a flag. motion-path, motion-offset, motion-rotation and motion will be deprecated, to be removed in M58. We are not shipping any new behavior with this intent.

Link to “Intent to Implement” blink-dev discussion

Covered by original Intent to Implement

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://goo.gl/WjA4lQ

Debuggability

No changes needed.

Interoperability and Compatibility Risk

We are the first browser shipping Motion Path. Each current property has usage below 0.02%.

The decision has been made to move to new property names, so we increase interoperability risk the longer we ship only the old names.

The spec still has some open issues, and more examples need to be added. In particular, the offset shorthand is still under discussion. Working under the original Intent to Implement, we will implement the additional features behind a flag. As we are the first browser to ship, there is always the risk of the spec changing further.

OWP launch tracking bug

crbug.com/645840

Entry on the feature dashboard

https://www.chromestatus.com/features/6390764217040896

[Chris Harrelson]

Hi,

It sounds like you'd like to rename the properties in one release?

0.02% is not *that* low. Is there additional reason to believe this won't cause a problem? Why not at least deprecate the old name for a release or two, to allow usage to drive down?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Eric]

The old names (motion-path, motion-offset, motion-rotation and motion) will be temporarily retained with a deprecation warning, and will be removed in M58.

[Chris Harrelson]

Oh sorry, I missed the M58 reference.

LGTM1

[Eric]

Correction to the intent: motion will be renamed to offset at the same time as the motion-* properties are renamed. This will not happen behind a flag.

[Elliott Sprehn]

This feels like a lot of churn when we just told people to get off SMIL and use this instead. What's the motivation for breaking people again?

[Shane Stephens]

It's a change the WG wanted to make - while there is a degree of churn I think it's better to remain aligned to the spec so that we can be interoperable when other vendors implement.

I'll raise the change at TPAC to get a sense for whether the WG is happy with the names now (this will be well before the name change hits stable). If there's likely to be more churn then we can discuss whether to avoid making the change now.

Cheers,

    -Shane

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

On Mon, Sep 12, 2016 at 9:26 PM, 'Shane Stephens' via blink-dev <blin...@chromium.org> wrote:

It's a change the WG wanted to make - while there is a degree of churn I think it's better to remain aligned to the spec so that we can be interoperable when other vendors implement.

I have to say that I disagree with this characterization of implementations needing to make breaking changes just because "the WG liked the name better", and that making breaking implementation changes to follow the whims of the WG are the only way to achieve interop.  Eg. if we didn't change, would Edge really choose to match the spec instead of matching the expectations of the 0.02% of pages already using the API and being interoperable with Chrome? 

Healthy web evolution is a collaboration between the implementations and standards groups, making constant trade-offs to balance speed of evolution, web compatibility and API aesthetics.  If we're shipping APIs from one version of a spec and then the WG is really expecting us to inflict even small amounts of pain on our users and developers without any justification better than "we like the name better" then something is broken with this collaboration.

Obviously this case isn't a huge deal in itself (hardly the thing to create a big fight over), but developers are screaming about the unpredictability caused by the thousands of little breaking changes they have to put up with on the web more than on native platforms.  We owe it to them to be a bit more disciplined in our justifications for making breaking changes, and perhaps with choosing to ship APIs defined only in draft specs from the FXTF in the first place.  One alternative of course  is to unship this API now and wait until the spec reaches REC and has been shipped by other browsers before risking more churn.

To help quantify the trade offs better I've done a couple quick HTTPArchive searches.  I found only 9 sites in the top 500k using 'motion-path' in CSS, and 7 using it in JavaScript (json below).  I'm surprised that we'd hit 0.02% of page views with only 0.003% of top sites having any reference at all.  Maybe worth more digging, testing of affected sites for the impact and possible site outreach?

Rick

 

[

  {

    "bodies_page": "http://www.oddschecker.com/",

    "bodies_url": "http://static.oddschecker.com/OC/css/compiled/OC/content/homepage.css?v=1.0.35"

  },

  {

    "bodies_page": "http://www.vroptimal.com/",

    "bodies_url": "https://www.vroptimal.com/assets/application-02550fcc3c0c1edbd463caa5157720ae.css"

  },

  {

    "bodies_page": "http://www.caniuse.com/",

    "bodies_url": "http://caniuse.com/"

  },

  {

    "bodies_page": "http://www.mackenzieinvestments.com/",

    "bodies_url": "http://www.mackenzieinvestments.com/assets/wro/74b691c5d1a9668f732020ea71efc0a393f59d2d/mfcstyle.css?minimize=true"

  },

  {

    "bodies_page": "http://www.oddschecker.com.au/",

    "bodies_url": "http://static.oddschecker.com/OC/css/compiled/AU/content/homepage.css?v=1.0.34"

  },

  {

    "bodies_page": "http://www.mediaevent.de/",

    "bodies_url": "http://www.mediaevent.de/"

  }

]

[

  {

    "bodies_page": "http://www.mmrcl.com/",

    "bodies_url": "https://www.mmrcl.com/home_page_map/"

  },

  {

    "bodies_page": "http://www.cardconnect.com/",

    "bodies_url": "https://cardconnect.com/site/themes/redwood/js/redwood.js"

  },

  {

    "bodies_page": "http://www.tripigator.com/",

    "bodies_url": "https://www.tripigator.com/static/js/common-fb.min.36ea2f5cf4bd.js"

  },

  {

    "bodies_page": "http://www.peppapig.com/",

    "bodies_url": "http://static.peppapig.com/assets/cache/1bcbe415a446dee4c52a0f09cd0c2092.js"

  },

  {

    "bodies_page": "http://www.monopolysky.com/",

    "bodies_url": "http://monopolysky.com/"

  },

  {

    "bodies_page": "http://www.wercker.com/",

    "bodies_url": "http://wercker.com/"

  },

  {

    "bodies_page": "http://www.agar.io/",

    "bodies_url": "http://agar.io/mc/agario.js?v=724"

  }

]

I'll raise the change at TPAC to get a sense for whether the WG is happy with the names now (this will be well before the name change hits stable). If there's likely to be more churn then we can discuss whether to avoid making the change now.

Cheers,

    -Shane

On Tue, Sep 13, 2016 at 11:07 AM Elliott Sprehn <esp...@chromium.org> wrote:

This feels like a lot of churn when we just told people to get off SMIL and use this instead. What's the motivation for breaking people again?

On Mon, Sep 12, 2016 at 5:07 PM, Eric <ericwi...@chromium.org> wrote:

Correction to the intent: motion will be renamed to offset at the same time as the motion-* properties are renamed. This will not happen behind a flag.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Shane Stephens]

Healthy web evolution is a collaboration between the implementations and standards groups, making constant trade-offs to balance speed of evolution, web compatibility and API aesthetics.  If we're shipping APIs from one version of a spec and then the WG is really expecting us to inflict even small amounts of pain on our users and developers without any justification better than "we like the name better" then something is broken with this collaboration.

I think I've given you the wrong impression. The WG didn't just change the name on a whim (it's a concerning sign that something may indeed be broken if this was your first assumption). There is no "motion" encoded in a motion path, and hence there was a justifiable concern that the properties would be confusing to developers.

When we take the risk of shipping a specification well before discussion has finished, we assume a burden of making reasonable adjustments, and this one doesn't seem unreasonable to me. Developers feel the pain of changes once per change, but they feel constant and ongoing pain when features and APIs are poorly named.

We can discuss why we decided to ship motion-* early here or elsewhere, but in this context I think it's enough to know that we did have that discussion and we did weigh the risks - in fact, there's an intent to ship that went to this list.

Our options are either:

(1) unship this API for now and wait for stabilization

(2) make the name change and continue to track the specification

Either way, we need to deprecate the old names immediately. I think it's also OK to alias them now (before branch point) as the rollback will be reasonably trivial if we decide to go with option (1). Perhaps we could make this even simpler by aliasing behind a flag that we can switch off if necessary.

Obtaining some level of assurance from the WG that the specification is stabilizing would hopefully swing us towards (2), as this gives developers who have adopted the feature an easy alternative (as opposed to no alternative). I am very happy to conduct a discussion at TPAC towards this end.

Cheers,

    -Shane Stephens

[Rick Byers]

On Mon, Sep 12, 2016 at 11:14 PM, Shane Stephens <sh...@google.com> wrote:

Healthy web evolution is a collaboration between the implementations and standards groups, making constant trade-offs to balance speed of evolution, web compatibility and API aesthetics.  If we're shipping APIs from one version of a spec and then the WG is really expecting us to inflict even small amounts of pain on our users and developers without any justification better than "we like the name better" then something is broken with this collaboration.

I think I've given you the wrong impression. The WG didn't just change the name on a whim (it's a concerning sign that something may indeed be broken if this was your first assumption).

I realize my concerns came across harsher than I intended, I'm sorry.  I know the style team does a great job being thoughtful about web compat while pushing the web ahead efficiently.

Mainly I want to emphasize that developers are telling us that the aggregate of many breaking changes are a big cost of web development and, as a result, for every non-zero-usage breaking change we want to do we as a community needs to articulate the cost/benefit trade-off and prove that we're being diligent and thoughtful if we're to improve our standing with developers and combat the "native mobile platforms are more developer friendly" meme.

I've seen first-hand the CSSWG typically do this very well in the past (and make changes contingent on the understanding that implementations may come back with compat experience different than predicted and so require a re-analysis).  I suspect this case is mainly about a failure to communicate the nuance of the analysis/discussion that's already been had here.

  

There is no "motion" encoded in a motion path, and hence there was a justifiable concern that the properties would be confusing to developers.

When we take the risk of shipping a specification well before discussion has finished, we assume a burden of making reasonable adjustments, and this one doesn't seem unreasonable to me.

It "feels" like it may not be unreasonable to me too, but there hasn't yet been enough data on this thread to make an informed decision.  Eg. if 0.01% page views are totally broken by this change then it's almost certainly not worth the cost.  I suspect the actual compat cost is orders of magnitude lower, but the feature team making the change should provide the evidence for that argument (eg. do the HTTP Archive query, spot-check some or all of the results).

 

Developers feel the pain of changes once per change, but they feel constant and ongoing pain when features and APIs are poorly named.

We can discuss why we decided to ship motion-* early here or elsewhere, but in this context I think it's enough to know that we did have that discussion and we did weigh the risks - in fact, there's an intent to ship that went to this list.

Our options are either:

(1) unship this API for now and wait for stabilization

(2) make the name change and continue to track the specification

 

Either way, we need to deprecate the old names immediately. I think it's also OK to alias them now (before branch point) as the rollback will be reasonably trivial if we decide to go with option (1). Perhaps we could make this even simpler by aliasing behind a flag that we can switch off if necessary.

There's a third option that it still seems like you're avoiding discussing: analyze the compat impact more thoroughly and, if it turns out it's actually at the bad end of 0.02% of page views, present the compat argument to the WG and ask them to reconsider the spec change rather than deprecate anything.

Realistically the risk is probably low enough here that we're not talking more than 30 minutes of work to make a compelling case that we should try to make the change (with the usual caveat that substantial feedback from users during beta should cause us to reconsider).

[Shane Stephens]

It "feels" like it may not be unreasonable to me too, but there hasn't yet been enough data on this thread to make an informed decision.  Eg. if 0.01% page views are totally broken by this change then it's almost certainly not worth the cost.  I suspect the actual compat cost is orders of magnitude lower, but the feature team making the change should provide the evidence for that argument (eg. do the HTTP Archive query, spot-check some or all of the results).

Justification for change: The feature doesn’t actually generate any motion at all, so it’s misleading to call it ‘motion’. Motion, in fact, is generated by the animations and transitions specification - but this is true of *all* positioning properties.

Web compatibility: As we’re the only vendor that implements this feature, any uses by definition are not currently web compatible. While we may be breaking some content, we’re not going to be causing content to render differently across browsers (in fact we're likely to be causing the opposite).

Usage: The most current usage count is just under 0.02%.  Eric conducted a sample of 32 sites that set motion and have high visit counts. The breakdown is as follows:

   * 11 sites set motion or motion-path to ‘none’ or similar.

 * 19 sites are tutorials for motion-path

 * 1 site uses the properties to show electrons animating around an atom. This obviously doesn’t work in other browsers (and viewing in other browsers doesn’t detract from the information content of the site).

 * 1 site uses the property in a media query, presumably to sniff Chrome

I’m somewhat conflicted about whether to count the tutorials as breaking or not, but it’s clear that apart from tutorials there are very few genuine uses of motion-path out there at the moment.

Other considerations: This feature is a visual enhancement, not a core feature. By removing it we might be preventing some animations from displaying, but we won’t be impacting the layout of any pages, hiding content, or breaking scripts (probably). This coupled with the web compatibility and usage arguments above indicates that users of the web won’t even notice the removal of the motion-* properties.

 

There's a third option that it still seems like you're avoiding discussing: analyze the compat impact more thoroughly and, if it turns out it's actually at the bad end of 0.02% of page views, present the compat argument to the WG and ask them to reconsider the spec change rather than deprecate anything.

This is true, and under the circumstances (a long delay between when the change was proposed and when it hit the specification) I'd feel justified in doing that if the compatibility impact was large enough. Based on the numbers above, I don't think it is.

Thanks,

    -Shane

[Philip Jägenstedt]

Looking at the spec and in particular the circles example it's clear that the feature does something in the absence of animation/motion, so absent compat concerns I agree it makes sense. But I can't get the example to work in Chrome with s/offset/motion/, should it work?

As for the risk, the use counter is triggered by the existence of the property, but maybe 'none' poisons the data? In this kind of scenario, it might be useful to add a target use counter that's only triggered when the property has an effect.

How about:

1. Ship offset-* and make motion-* aliases.
2. Maybe: Add a use counter for when motion-* aliases have an effect. Tricky because of aliasing, but in principle possible.
3. Reach out to any sites already found in HTTP Archive.
4. In 6 months, if use counters and HTTP Archive usage look good, deprecate and commit to removal at a specific date. Otherwise add the aliases to the spec.

Would that work? It's mostly deprecation/removal as usual, but with an agreement with the WG, where the WG accepts the risk of having to spec confusing (arguably) aliases. That seems reasonable to me, at least in the case of aliasing which is cheap both to spec and implement.

[Eric]

On Wednesday, September 14, 2016 at 10:46:18 PM UTC+10, Philip Jägenstedt wrote:

Looking at the spec and in particular the circles example it's clear that the feature does something in the absence of animation/motion, so absent compat concerns I agree it makes sense. But I can't get the example to work in Chrome with s/offset/motion/, should it work?

No, the circles example won't work yet. Angle paths weren't in last year's spec.  https://www.w3.org/TR/motion-1/#motion-path-property

path(<string>) and 'none' are the only motion-path values that Chrome has supported to date.

[Philip Jägenstedt]

Oh, so is it fair to say that the subset that Chrome does support only makes sense with some animation/motion, or is there a reasonable static usage of path(<string>)?

I didn't look very closely, but would it be possible to split the not-yet-supported functionality into new properties, and how heavily does that subset overlap with just using transforms?

[Philip Jägenstedt]

(I've talked a bit with Rick offline about this.)

Based on the information we already have, in particular the HTTP Archive analysis, we can be pretty confident that dropping support for motion-path will work out. We've removed things with much higher usage based on similar analysis and it's worked out before, e.g. defaultCharset.

So, I'd be happy to LGTM immediate aliasing + deprecation with a removal target 2-3 milestones away. In the unlikely event that removal doesn't work out due to a compat issue we can't get resolved, then we'll have to revisit.

Does that sound OK?

[Rick Byers]

That plan for deprecation/removal LGTM based on the provided data - thank you!

  

[Philip Jägenstedt]

LGTM2 assuming Eric and Shane like the plan.

[Chris Harrelson]

LGTM3 for the same plan.

[Shane Stephens]

I'm happy with this plan. Eric?

Cheers,

    -Shane

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Eric]

Yes, thanks everyone.

[Eric Willigers]

We have received a late change to a property name: offset-rotation is being changed to offset-rotate

https://github.com/w3c/fxtf-drafts/issues/70

It is too late to change the offset-* properties we are about to ship in M55, so we propose holding off with the blog post and deprecation message, and shipping offset-rotate in M56.

Proposed plan:  goo.gl/XFvGR8

[PhistucK]

Can you just disable the feature in Chrome 55?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

Yeah let's merge a disable flag flip.

[Eric Willigers]

The motion-* properties are implemented as aliases of the offset-* properties. 

Disabling the offset properties with a flag also affects the motion-* properties.

[Chris Harrelson]

The proposed plan at goo.gl/XFvGR8 sounds fine to me.