On Sun, Nov 23, 2014 at 4:53 AM, Nottingham, Mark <mnotting@akamai.com> wrote: > > > On 22 Nov 2014, at 4:05 am, Mark Watson <watsonm@netflix.com> wrote: > > > > Mark (Nottingham) noted that we need to distinguish between "new" > features and features whose historical context created decisions that are > suboptimal today. I'll certainly be adding text to the doc to make a path > forward for those types of APIs more clear. > > > > There's a distinction between entirely new functionality and new > replacements for to-be-deprecated, but widely used, functionality. > Completely new functionality has no existing users (sites) so you have a > true "green field" situation (e.g. Service Workers). If you are trying to > replace some existing widely-used legacy functionality, the situation is > different, since too many barriers in the path of the new thing may just > lead people to stick with the legacy solution longer. > > Yes; see: > > https://gist.github.com/mnot/38df717849b775eec3a4/550e9adc5791786ca1c8a0ade72712c466ef6978#adapting-existing-specifications > … for what I was thinking. > I took a stab at this in https://w3c.github.io/webappsec/specs/powerfulfeatures/#restrictions. Feedback? CCing public-geolocation@, as I've used that API as an explicit example of something that would fall into this category. Does the strawman deprecation plan make sense? -mike -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 9 December 2014 14:40:32 UTC