Intent to Deprecate: step-middle timing function

[Suzy Howlett]

Primary eng email

su...@chromium.org

 

Summary

Now that the frames() timing function has shipped in M60 [blink-dev intent, chromestatus entry], I'd like to deprecate step-middle and the steps() timing function with position: middle in M61, with an aim to remove in M62.

 

Motivation

The step timing function with position: middle, along with the shorthand step-middle, has been superseded by the frames timing function. See the W3C discussion from Mar 2016. The new CSS Timing Functions spec includes the frames timing function and not the step timing function with position: middle.

 

Interoperability and Compatibility Risk

Removing this feature overall improves our position.

Web Animations spec: Issue 5 of the Web Animations working draft says "step-middle and the middle keyword will likely be removed in favor of a frames() timing function.", and the editor's draft Time Transformations section has now been updated to point to the CSS Timing Functions spec, which includes frames and not step-middle.

Chrome: Currently allows step-middle in Web Animations only, and not in CSS Animations.

Firefox: Never shipped step-middle, in favour of frames. See Mozilla bug comment 27 and following, and the request to publish the FPWD of CSS Timing Functions.

Edge: Has not implemented step-middle
Safari: Has not implemented step-middle
Web developers: The W3C discussion about moving from step-middle to frames suggests the meaning of step-middle is unintuitive.

Alternative implementation suggestion for web developers

The frames() timing function is the intended replacement for the step timing function with position: middle.

 

Usage information from UseCounter

No UseCounter has yet been implemented. This will be added with the deprecation warning.

 

OWP launch tracking bug

http://crbug.com/646265

Entry on the feature dashboard

Will be incorporated under the existing chromestatus entry for the frames timing functions https://www.chromestatus.com/feature/5189363944128512

 

Requesting approval to remove too?

No. I will implement a deprecation warning and use counter for M61, aiming for removal in M62.

[Jochen Eisinger]

It's a bit unfortunate that there's no use counter yet, as we'll have to decide on removal before the use counter hit stable. Do you have other signals on what the usage might look like right now?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFV_mdpa883%2BoKxPR0atNdMqKyouZqFSDtGWBFM3Zeoy0_6a3g%40mail.gmail.com.

[Suzy Howlett]

Yeah, it's a little tough.

Given that we only allow step-middle in Web Animations, and not CSS Animations, usage will necessarily be lower than the Web Animations usage: https://www.chromestatus.com/metrics/feature/timeline/popularity/773 This is currently around 0.3%.

Given also that we're the only browser to have shipped step-middle, I anticipate that the usage will be substantially lower than that.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuidrgfUZFLUVag_VX8o41gAfLYd1D0sEzxCai9PzpkQRGQ%40mail.gmail.com.

[Jochen Eisinger]

ok, sounds good!

[Philip Jägenstedt]

Even if it's not certain that it'll work out, including "will be removed in M62" in the deprecation message is probably best, so should we upgrade this to an Intent to Deprecate and Remove? I'll static_cast<LGTM>("sounds good") and LGTM2 if you need it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuie27jO92ui2WHJb1WGj5%3DWe8JDCdk--6PPppULcWk33Eg%40mail.gmail.com.

[Chris Harrelson]

Hi,

We don't deprecate without removal timelines any more except in special circumstances, so this should be an intent to deprecate & remove. Also, is there a particular reason to rush? Why not wait for the UseCounter to gather more data?

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYd7S_-Mir4mZAnorW_fTKSjWEPLbG6jXr7o6DrapP-BQg%40mail.gmail.com.

[Rick Byers]

Perhaps an HTTP Archive search could give us enough confidence to deprecate with a planned removal milestone here (which we'd then validate via the UMA stats prior to actual removal)?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8tvBTB9N_d3ohv9D%3D42M1mQwKsDZFa2yvXn8QeAoQuCQ%40mail.gmail.com.

[Suzy Howlett]

On Thu, Jun 1, 2017 at 1:27 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

We don't deprecate without removal timelines any more except in special circumstances, so this should be an intent to deprecate & remove. Also, is there a particular reason to rush? Why not wait for the UseCounter to gather more data?

Chris

No, there's no particular reason to rush, if we can't get reasonable usage indications in a single release.

Re: "Intent to Deprecate" vs "Intent to Deprecate and Remove":

I was going off https://docs.google.com/document/d/1Z7bbuD5ZMzvvLcUs9kAgYzd65ld80d5-p4Cl2a04bV0/edit which states

"""

Requesting approval to remove too?

“No” means you will be showing a deprecation warning and counting feature usage with the intent of removing support.  Please indicate the milestone you intend to remove the API by (which should be included in the deprecation message).

 

“Yes” means the deprecation is small and you’d like to actually remove support for the feature now. If “yes,” please change the title of the email to “Intent to Deprecate and Remove: ...”.

"""

I had been intending to follow up with an "Intent to Remove" later. I'm happy to rename this thread instead if you think that's appropriate.

On Fri, Jun 2, 2017 at 6:33 AM Rick Byers <rby...@chromium.org> wrote:

Perhaps an HTTP Archive search could give us enough confidence to deprecate with a planned removal milestone here (which we'd then validate via the UMA stats prior to actual removal)?

I totally forgot about HTTP Archive for this.

 

SELECT page, url

FROM [httparchive:har.2017_05_15_chrome_requests_bodies]

WHERE body CONTAINS 'step-middle'

AND NOT REGEXP_MATCH(url, 'web-animations(-next)?(-lite)?(.min)?\\.js')

124 results

(The second clause is an attempt to exclude the web animations polyfill, although that's no guarantee I'm not getting other such named javascript files. Without that clause, I get 152 results.)

Note that "step-middle" has an exact replacement with frames: "step-middle" and its equivalent "steps(1, middle)" is identical to "frames(2)".

For x>1, "steps(x, middle)" is slightly different from "frames(x+1)", but there don't seem to be any instances of this in the wild:

SELECT page, url

FROM [httparchive:har.2017_05_15_chrome_requests_bodies]

WHERE REGEXP_MATCH(body, 'steps\\([0-9]*, middle')

 

0 results

What do you think?

[Philip Jägenstedt]

On Mon, Jun 5, 2017 at 8:48 AM Suzy Howlett <su...@chromium.org> wrote:

On Thu, Jun 1, 2017 at 1:27 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

We don't deprecate without removal timelines any more except in special circumstances, so this should be an intent to deprecate & remove. Also, is there a particular reason to rush? Why not wait for the UseCounter to gather more data?

Chris

No, there's no particular reason to rush, if we can't get reasonable usage indications in a single release.

Re: "Intent to Deprecate" vs "Intent to Deprecate and Remove":

I was going off https://docs.google.com/document/d/1Z7bbuD5ZMzvvLcUs9kAgYzd65ld80d5-p4Cl2a04bV0/edit which states

"""

Requesting approval to remove too?

“No” means you will be showing a deprecation warning and counting feature usage with the intent of removing support.  Please indicate the milestone you intend to remove the API by (which should be included in the deprecation message).

 

“Yes” means the deprecation is small and you’d like to actually remove support for the feature now. If “yes,” please change the title of the email to “Intent to Deprecate and Remove: ...”.

"""

I had been intending to follow up with an "Intent to Remove" later. I'm happy to rename this thread instead if you think that's appropriate.

Sorry that this was confusing, it was never updated to reflect our thinking about deprecations without a known removal date. I've now updated it to say:

“Yes” means that you’d like to remove the feature immediately or at a specified future milestone. Please indicate the milestone for removal, and include it in the deprecation message. If “yes,” please change the title of the email to “Intent to Deprecate and Remove: ...”.

 

“No” means you will be showing a deprecation warning with no milestone for removal. This is discouraged, see http://www.chromium.org/blink/removing-features

Is that better? (I've also changed the title and https://bit.ly/blinkintents.)

On Fri, Jun 2, 2017 at 6:33 AM Rick Byers <rby...@chromium.org> wrote:

Perhaps an HTTP Archive search could give us enough confidence to deprecate with a planned removal milestone here (which we'd then validate via the UMA stats prior to actual removal)?

I totally forgot about HTTP Archive for this.

 

SELECT page, url

FROM [httparchive:har.2017_05_15_chrome_requests_bodies]

WHERE body CONTAINS 'step-middle'

AND NOT REGEXP_MATCH(url, 'web-animations(-next)?(-lite)?(.min)?\\.js')

124 results

(The second clause is an attempt to exclude the web animations polyfill, although that's no guarantee I'm not getting other such named javascript files. Without that clause, I get 152 results.)

Note that "step-middle" has an exact replacement with frames: "step-middle" and its equivalent "steps(1, middle)" is identical to "frames(2)".

For x>1, "steps(x, middle)" is slightly different from "frames(x+1)", but there don't seem to be any instances of this in the wild:

SELECT page, url

FROM [httparchive:har.2017_05_15_chrome_requests_bodies]

WHERE REGEXP_MATCH(body, 'steps\\([0-9]*, middle')

 

0 results

What do you think?

Do you mean that resources matching 'steps\\([0-9]*, middle' (0) are the only ones which would see any change in behavior, or how should one interpret the 124 resources matching 'step-middle'?

[Rick Byers]

LGTM3 to deprecate now with a plan to remove in M62 (after double-checking that the UseCounter data isn't huge).  Please follow up here with the UseCounter data from M61 dev or beta channel once you have it.

On Wed, Jun 7, 2017 at 5:53 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Mon, Jun 5, 2017 at 8:48 AM Suzy Howlett <su...@chromium.org> wrote:

[Suzy Howlett]

On Fri, Jun 9, 2017 at 3:32 AM Rick Byers <rby...@chromium.org> wrote:

LGTM3 to deprecate now with a plan to remove in M62 (after double-checking that the UseCounter data isn't huge).  Please follow up here with the UseCounter data from M61 dev or beta channel once you have it.

  

Thanks all. I'll go ahead and get the deprecation patch up for review.

On Wed, Jun 7, 2017 at 5:53 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Do you mean that resources matching 'steps\\([0-9]*, middle' (0) are the only ones which would see any change in behavior, or how should one interpret the 124 resources matching 'step-middle'?

Yes, that is my understanding. Any page using "step-middle" (or the equivalent "steps(1, middle)") should be able to directly substitute "frames(2)" and have the same behaviour.  Any other "steps(*, middle)" would get a slightly different effect using frames.

[Philip Jägenstedt]

OK, so that means that the 124 resources are easy to fix by simple substitution, but not that they'll be unaffected by the change in the first place. Still LGTM in light of other implementations.

[Alan Cutter]

We are no longer shipping the "frames" timing function (intent update), that means there will no longer be a drop in replacement for step-middle and step(x, middle) until the name has stabilised in spec.

The UMA counts for "DeprecatedTimingFunctionStepMiddle" on Beta, Dev and Canary are low enough that it shows up as 0% in the UMA tool.

Is it still okay to go ahead with deprecation & removal?

The deprecation message will be updated to not include "Please use the frames timing function instead".

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfX2c4cjGj6hOf-Fo-uFsQ4zxj-OyGfuZ0CR%3DYAoRaHuA%40mail.gmail.com.

[Philip Jägenstedt]

If usage really is zero, then going ahead with deprecation and removal sounds OK to me. What we're balancing is the risk of keeping it and seeing usage grow vs. the pain of people who are using and now don't have a replacement. However, if there also isn't a replacement in any other browser, that would make the risk much lower. Is that the case?