Intent to Deprecate as vendor-specific: webkitRequestAnimationFrame

[Philip Jägenstedt]

This is a test balloon for "Criteria for deprecation vs. removal":
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eplNSf8oDfw/S-Wjh7e9JpcJ

Primary eng (and PM) emails

phi...@opera.com

Summary

Kindly inform Web developers that they should use requestAnimationFrame instead with this message:

"'webkitRequestAnimationFrame' is vendor-specific. Please use the standard 'requestAnimationFrame' instead."

Motivation

Pages that fails to use the standard requestAnimationFrame when available make it impossible for webkitRequestAnimationFrame to ever be removed. More importantly, it can contribute to browser engine lock-in. (Not must, because it's possible the script would fall back to the standard API.)

Compatibility Risk

None, removal is not imminent.

Usage information from UseCounter

~0.35%: http://www.chromestatus.com/metrics/feature/timeline/popularity/14

This is above the threshold for removal, but low enough that developers won't get spammed with warnings and start (continue?) ignoring them.

Entry on chromestatus.com

http://www.chromestatus.com/features/5233400470306816

Requesting approval to remove too?

No.

[Adam Barth]

LGTM

[Elliott Sprehn]

They have slightly different behavior as well (the arguments are in different time bases). We might try making them match which removes the implantation burden since it becomes just an idl alias, but perhaps that's too crazy.

[Philip Jägenstedt]

Elliott's message made me look closer at the IDL...

I'd like to amend the intent with the same treatment for webkitCancelAnimationFrame and webkitCancelRequestAnimationFrame, both ImplementedAs=cancelAnimationFrame. They currently aren't counted at all, but ought to be less common than webkitRequestAnimationFrame itself. It would be sad if a Web developer fixes webkitRequestAnimationFrame but forgets these two.

Making webkitRequestAnimationFrame an alias of requestAnimationFrame would be nice, but doesn't really seem doable if I'm reading the code correctly.

Philip

[Chris Harrelson]

How about we make a web page for each feature that is in deprecation or removal status, which contains (:

- Explanation of recommended steps to replace the feature with an equivalent alternative

- Date of deprecation and/or removal

- Expected date or threshold for next step (for deprecation, next step is removal)

- Rationale

- Link to accompanying blink-dev thread(s) and bug ids

- Instructions on how to follow-up to provide comments or feedback on blink-dev, if desired

Then link to this from deprecation messages, and from master pages/the Chromium blog as appropriate. I don't think this should be the same as the chromestatus.com page, though the latter can/should link to the deprecation page.

Such pages should be very easy to create on the already-existing chromium/blink Google Sites page. Probably they will also index better in search?

I don't think an email thread is the best place for canonical documentation, nor is it as easy to link to it or update it with information pertinent to users of APIs.

Chris

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

[Max Heinritz]

I agree we could be doing a better job disseminating deprecation and removal information.

On Tue, Mar 11, 2014 at 9:48 AM, Chris Harrelson <chri...@chromium.org> wrote:

How about we make a web page for each feature that is in deprecation or removal status, which contains (:

- Explanation of recommended steps to replace the feature with an equivalent alternative

- Date of deprecation and/or removal

- Expected date or threshold for next step (for deprecation, next step is removal)

- Rationale

- Link to accompanying blink-dev thread(s) and bug ids

- Instructions on how to follow-up to provide comments or feedback on blink-dev, if desired

Then link to this from deprecation messages, and from master pages/the Chromium blog as appropriate.

 

I don't think this should be the same as the chromestatus.com page, though the latter can/should link to the deprecation page.

Curious: why not?  This seems like a natural extension of chromestatus.com, but isn't something we've focused on.

Such pages should be very easy to create on the already-existing chromium/blink Google Sites page. Probably they will also index better in search?

I don't think an email thread is the best place for canonical documentation, nor is it as easy to link to it or update it with information pertinent to users of APIs.

Another resource similar to what you're describing is the Blink Intents Spreadsheet.  That could be a starting point for such a page.

[Chris Harrelson]

On Tue, Mar 11, 2014 at 9:58 AM, Max Heinritz <m...@chromium.org> wrote:

I agree we could be doing a better job disseminating deprecation and removal information.

On Tue, Mar 11, 2014 at 9:48 AM, Chris Harrelson <chri...@chromium.org> wrote:

How about we make a web page for each feature that is in deprecation or removal status, which contains (:

- Explanation of recommended steps to replace the feature with an equivalent alternative

- Date of deprecation and/or removal

- Expected date or threshold for next step (for deprecation, next step is removal)

- Rationale

- Link to accompanying blink-dev thread(s) and bug ids

- Instructions on how to follow-up to provide comments or feedback on blink-dev, if desired

Then link to this from deprecation messages, and from master pages/the Chromium blog as appropriate.

 

I don't think this should be the same as the chromestatus.com page, though the latter can/should link to the deprecation page.

Curious: why not?  This seems like a natural extension of chromestatus.com, but isn't something we've focused on.

Because the chromestatus.com page has a lot of other stuff going on that confuses the issue. e.g. http://www.chromestatus.com/features/5233400470306816. The page linked to should be a very easy to read and understand format whose sole purpose is to inform and guide developers about how to react to these deprecations & removals.

If you mean why not host it at chromestatus.com at some other sub-URL, I don't mind, but I'm just thinking of a way that is easy to create/edit/update without manually editing HTML and pushing it to a custom git repository.

[PhistucK]

(Adding public-webplatform)

Since these deprecations are for the benefit of the entire web platform and you want everyone (not only web developers that develop mainly for Blink) to stop using these, I think the natural place for the generic page with all of the information and documentation a developer needs is docs.webplatform.org.

There could be a section for deprecated features and section with instructions for replacements and alternatives.

☆PhistucK

[Tom Wiltzius]

Be advised that as of early 2013, there are unfortunately many sites that relied on the old time base in webkitRequestAnimationFrame. The major example is anything built with GWT 2.4 or lower. See crbug.com/158910

While it's likely that by now there are fewer of these sites, I would be wary of harmonizing the implementations to the standard requestAnimationFrame.

Fortunately at least those particular sites feature-detect webkitRequestAnimationFrame and if it isn't present simply use a timer. While sub-optimal, they shouldn't break if we removed webkitRequestAnimationFrame entirely (but will break if we make webkitRequestAnimationFrame use the requestAnimationFrame semantics).

In the meantime, however, I think deprecation of the prefixed version and a warning for developers is a great idea, especially because the standard version has different semantics.

[Eric Willigers]

We now have two years of statistics.

Current usage:

webkitCancelRequestAnimationFrame < 0.002%

webkitCancelAnimationFrame < 0.015%

webkitRequestAnimationFrame  < 0.04%

It is time to remove webkitCancelRequestAnimationFrame.

[PhistucK]

Can you use the same trick document.all uses for webkitRequestAnimationFrame?

var foo = document.all || 'unsupported';

foo; // 'unsupported'

document.all.bla // Does not throw, because document.all actually exists

I bet usage will go down without breaking websites (those that require them without feature testing will still work and the data will be gathered).

Of course, that means that websites that feature detect only the prefixed method and just give up otherwise (show an unsupported browser message) will stop working, but I guess those are mainly demos.

☆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.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of PhistucK

> Can you use the same trick document.all uses for webkitRequestAnimationFrame?

No, we must not introduce more objects which violate the semantics of the JavaScript spec.

[PhistucK]

While I agree with you, adding them temporarily (two releases or something) in order to remove deprecated APIs does not sound too bad.

☆PhistucK

[Philip Jägenstedt]

When usage is high but you suspect there's feature detection in place, httparchive analysis can help. It's rather tedious work to sort through the mountain of cases that won't break in search for some that would, but it's doable. I think we have plenty of things that could plausibly be removed given such analysis. Not sure about webkitRequestAnimationFrame, that Edge has added it is discouraging.

Note that the document.all trick wouldn't help with 'webkitRequestAnimationFrame' in window or code that uses try { } catch() { }.

[PhistucK]

Right, it will not help in those cases, but it will weed out a lot of var foo = window.webkitRequestAnimationFrame || window.requestAnimationFrame that I suspect are the main offenders.

☆PhistucK

[PhistucK]

(Removed some bounced e-mail addresses)

☆PhistucK

[Philip Jägenstedt]

It probably would account for the majority of cases, but just httparchive analysis would get you a better understanding of the situation in shorter time, without messing with bindings. FWIW, there are only 458 resources that contain 'webkitRequestAnimationFrame' but not 'requestAnimationFrame', so there's a decent chance.