- From: PhistucK <phistuck@gmail.com>
- Date: Sat, 15 Mar 2014 00:13:32 +0200
- 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>
- Message-ID: <CABc02_KF3yhCdO5_purADO6Qkzcsq7fN5srvBDmNSJ_jGSZMaQ@mail.gmail.com>
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