W3C home > Mailing lists > Public > public-webplatform@w3.org > March 2014

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

From: PhistucK <phistuck@gmail.com>
Date: Thu, 13 Mar 2014 21:55:42 +0200
Message-ID: <CABc02_LH4ZATBcL3N=qcMhVUGJ9jTPEvE-H3a9pP29-XYjAWHw@mail.gmail.com>
To: Chris Harrelson <chrishtr@chromium.org>
Cc: Max Heinritz <meh@chromium.org>, Philip Jägenstedt <philipj@opera.com>, Elliott Sprehn <esprehn@google.com>, Adam Barth <abarth@google.com>, blink-dev <blink-dev@chromium.org>, "public-webplatform@w3.org" <public-webplatform@w3.org>
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.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.
>>>>
>>>
>>>
>>
>
Received on Thursday, 13 March 2014 19:57:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:59 UTC