Re: [blink-dev] Intent to Deprecate as vendor-specific: webkitRequestAnimationFrame

(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*


On Tue, Mar 11, 2014 at 7:02 PM, Chris Harrelson <chrishtr@chromium.org>wrote:

>
>
>
> On Tue, Mar 11, 2014 at 9:58 AM, Max Heinritz <meh@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 <chrishtr@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.
>
>
>>
>>> 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<https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AjGgk26K1Cc-dHJKNGtlLVlmSGRIYVR3LVRGYnVCRVE&usp=drive_web#gid=0>.
>>  That could be a starting point for such a page.
>>
>>>
>>> Chris
>>>
>>>
>>> On Tue, Mar 11, 2014 at 1:27 AM, Philip Jägenstedt <philipj@opera.com>wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> On Tue, Mar 11, 2014 at 3:10 PM, Elliott Sprehn <esprehn@google.com>wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> On Tuesday, March 11, 2014, Adam Barth <abarth@google.com> wrote:
>>>>>
>>>>>> LGTM
>>>>>>
>>>>>> On Tue Mar 11 2014 at 12:55:16 AM, Philip Jägenstedt <
>>>>>> philipj@opera.com> wrote:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> philipj@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<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
>>>>>>
>>>>>>
>>>>  To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscribe@chromium.org.
>>>>
>>>
>>>
>>
>  To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscribe@chromium.org.
>