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

I understand the desire for developer participation and this is the only
thing that may come out of including a link to the discussion, but I still
think it contains a lot of information through which a developer would not
waste time to sift, much like including the link to the spreadsheet on a
release notes blog post is (which I understand is not going to happen
anymore and I appreciate that).
If you still want to link to the discussion, maybe you can include a
consensus post with all of the details, including pros and cons (if the
decision was not as smooth as an intent post and three LGTMs that
followed), after the third LGTM is posted and link directly to that post
(it can still be in the intent thread, but, still, a summary post for the
average developer - "The FEATURE-IDENTIFIER is being deprecated due to X,
Y, Z. Alternatives - X, Y, Z. Rough timeline for removal - Chrome X. Usage
counter link. See the rest of the thread for further discussion. Any
feedback is welcome." or something like that).
While I realize this is more time consuming than simply linking to the
thread and hoping for participation that might never come, it is much
clearer to the developer that simply clicked on a link and is not familiar
(and should not be familiar) with the internal (though public) deprecation
process of Blink.


☆*PhistucK*


On Sat, Mar 15, 2014 at 12:23 AM, Max Heinritz <meh@chromium.org> wrote:

> IMO, the original "Intent to Deprecate" messages<https://docs.google.com/a/chromium.org/document/d/1Z7bbuD5ZMzvvLcUs9kAgYzd65ld80d5-p4Cl2a04bV0/edit>are a great summary for developers.  They include a description of the
> change, the motivation, cross-browser compatibility info, and (as of
> yesterday) alternative implementation options.
>
> I'm wary of creating a separate dashboard.  In my experience, it's
> difficult to maintain two sources of truth.  chromestatus.com could<https://github.com/GoogleChrome/chromium-dashboard/issues/101>serve this purpose if it's truly necessary.
>
> Another concern is that we'd get a lot more complaints from developers on
> this list.
>
>
> On Fri, Mar 14, 2014 at 3:13 PM, PhistucK <phistuck@gmail.com> wrote:
>
>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>