Re: Blink Deprecation Dashboard WAS Re: [blink-dev] Intent to Deprecate as vendor-specific: webkitRequestAnimationFrame

I'm not sure, sometimes there will be a mistake in the first post that's
only corrected later in the thread, or maybe the perfect polyfill code is
only posted far later. The inability to edit the linked page to be brief
and accurate seems like a problem to me.

Philip
On Mar 15, 2014 5:10 AM, "Max Heinritz" <meh@chromium.org> wrote:

> Just chatted with Chris.  He had an interesting idea: link from the
> deprecation warning in the DevTools Console to the feature's "Intent to
> Deprecate" thread.  This would require code changes in Blink, but seems
> like a good idea to me.
>
> Anyone interested in implementing this?
>
> Max
>
>
> On Thu, Mar 13, 2014 at 3:20 PM, Max Heinritz <meh@chromium.org> wrote:
>
>> I updated the "Intent to Deprecate" template<https://docs.google.com/a/chromium.org/document/d/1Z7bbuD5ZMzvvLcUs9kAgYzd65ld80d5-p4Cl2a04bV0/edit>
>> :
>>
>> Added:
>>
>> Alternative implementation suggestion for web developers
>>
>> If this feature goes away, what other techniques can developers use to
>> achieve the same effects?
>>
>>
>> Expanded "chromestatus.com entry" section to include MDN:
>>
>>  Entry on chromestatus.com and/or MDN
>>
>> Please link to this feature’s entry on chromestatus.com/features (example
>> link <http://www.chromestatus.com/features/5556931766779904>) and/or
>> MDN.  If the feature has an entry, please indicate that it is now
>> deprecated Chrome.  If this feature doesn’t have a page or entry, you may
>> be asked to create one.
>>
>>
>> Going forward, my focus in this area will be on making sure the Chromium
>> blog release notes are complete and accurate in terms of deprecations and
>> removals, per the process I described in this thread<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Np1MKxgFXxM>.
>>  I plan to enumerate the new deprecations and removals in each release and
>> link to the relevant intent threads.
>>
>> Please remember to send "Intents" for all non-trivial web-facing changes.
>>
>>
>> On Thu, Mar 13, 2014 at 12:55 PM, PhistucK <phistuck@gmail.com> wrote:
>>
>>> Regarding MDN - you do not need to "get them", just edit the relevant
>>> pages.
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Thu, Mar 13, 2014 at 5:43 PM, Chris Harrelson <chrishtr@chromium.org>wrote:
>>>
>>>> I don't mind if the deprecation page is on chromestatus.com if that is
>>>> the cleanest and least-repetitive engineering solution, but we do need
>>>> pages that focus on each specific feature. These pages can be linked to
>>>> from deprecation warnings and blogposts, and also show up in search
>>>> results. I would guess that chromestatus.com indexes poorly today in
>>>> websearch for terms specific to particular web features, or in cases where
>>>> it does index ok the deep link doesn't work.
>>>>
>>>> MDN does a great job of this, and their feature matrix also lists
>>>> deprecation status in some cases. How about we also get them to list
>>>> deprecation status for Chrome when features are deprecated?
>>>>
>>>>
>>>> On Wed, Mar 12, 2014 at 5:26 PM, Max Heinritz <meh@chromium.org> wrote:
>>>>
>>>>> TL;DR I don't think we should prioritize building a deprecation
>>>>> dashboard, but if we were to do it, chromestatus.com would be the
>>>>> right starting point.
>>>>>
>>>>> chromestatus.com has a backend database for keeping track of platform
>>>>> features, their relationship to Chrome releases, and links to accompanying
>>>>> bug ids.  Each feature also has a comment field for further elaboration on,
>>>>> say, alternative implementation approaches.  IMO, it's a natural starting
>>>>> point for a deprecation dashboard.
>>>>>
>>>>> In fact, the existing features page already shows deprecated features,
>>>>> but we just haven't really been using it for that purpose.  (I can only
>>>>> find one deprecated feature<http://www.chromestatus.com/features/5067649092419584>
>>>>>  listed.)
>>>>>
>>>>> I agree the main feature list <http://chromestatus.com/features> is
>>>>> overwhelming if you're *only* interested in features being
>>>>> deprecated.  Perhaps we could have another view of the data (e.g.
>>>>> /features/deprecated) or a default filter on the main page (e.g.
>>>>> /features?q=deprecated).
>>>>>
>>>>> However, it's not clear to me how much traffic this dedicated page
>>>>> would get, especially if we do a thorough job with the curated Chromium
>>>>> release blog posts.  I question how important it is relative to other work.
>>>>>  Upon some reflection, I think the current process is fine<https://groups.google.com/a/chromium.org/d/msg/blink-dev/Np1MKxgFXxM/Bd29z9966V4J>and we just messed up in the case of showModalDialog.
>>>>>
>>>>> What do you all think?
>>>>>
>>>>> For now, I filed two issues to track these ideas:
>>>>>
>>>>>    - Add "Removed" as an option for the feature's status<https://github.com/GoogleChrome/chromium-dashboard/issues/100>
>>>>>     (P1)
>>>>>     <https://github.com/GoogleChrome/chromium-dashboard/issues/100>
>>>>>    - Create a subdashboard specifically for deprecated and removed
>>>>>    features<https://github.com/GoogleChrome/chromium-dashboard/issues/101>
>>>>>     (P3)
>>>>>
>>>>> If anyone has cycles and is interested in working on a Polymer web app
>>>>> (ie chromestatus.com), feel free to submit patches!
>>>>> https://github.com/GoogleChrome/chromium-dashboard
>>>>>
>>>>> On Wed, Mar 12, 2014 at 10:56 AM, PhistucK <phistuck@gmail.com> wrote:
>>>>>
>>>>>> (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.compage, 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>