- From: PhistucK <phistuck@gmail.com>
- Date: Thu, 13 Mar 2014 21:55:42 +0200
- 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>
- Message-ID: <CABc02_LH4ZATBcL3N=qcMhVUGJ9jTPEvE-H3a9pP29-XYjAWHw@mail.gmail.com>
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