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: Sat, 15 Mar 2014 00:13:32 +0200
Message-ID: <CABc02_KF3yhCdO5_purADO6Qkzcsq7fN5srvBDmNSJ_jGSZMaQ@mail.gmail.com>
To: Max Heinritz <meh@chromium.org>
Cc: Chris Harrelson <chrishtr@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>
I think this is way too verbose for the average developer that wants to
know what is going on. Sometimes these threads can be long and tedious.
A summary page is much preferred, with a link to the raw discussion.


☆*PhistucK*


On Sat, Mar 15, 2014 at 12:09 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Friday, 14 March 2014 22:14:40 UTC

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