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

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