Hello again, I'd like to revise my proposal on deprecating HTML notifications in Chrome extensions: I would like to make the feature runtime-enabled, and leave it enabled for Chrome extensions until there is a suitable replacement. Once we have a replacement, we can follow the deprecation plan I sketched earlier.
It sounds like the Chrome web platform team is more OK with the idea of removing it from web content. Having the runtime switch would make it easy to implement both policies. I understand that having this code is a tax on the WebKit project, but it seems pretty small compared to other things that have been left in for other clients. - a On Mon, Feb 13, 2012 at 11:23 AM, Maciej Stachowiak <[email protected]> wrote: > > This plan sounds reasonable to me. No disruption of Chrome extensions in the > short term, but we would better align with each other and with standards in > the longer term. > > Jon? > > Regards, > Maciej > > On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote: > >> On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak <[email protected]> wrote: >>> >>> On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: >>> >>>> On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee <[email protected]> wrote: >>>>> 2. Remove HTML notifications. >>>>> >>>>> It has been removed from the spec, and we don't intend on ever supporting >>>>> HTML notifications. I brought this issue up before; is there an update on >>>>> this front from any other platforms? >>>> >>>> HTML notifications are a pretty popular feature in Chrome's extension >>>> system. As of a few months ago: >>>> >>>> * 614 extensions in our web store use createHTMLNotification >>>> * 72 have more than 10k users >>>> * 14 have more than 100k users >>>> * 3 have more than 500k users >>>> * 6.7M total actextension installs >>>> >>>> We can move developers off of this API, but not overnight. Is it >>>> possible to come up with a slower deprecation plan than "immediately"? >>> >>> Since HTML notifications are already under a separate feature flag, it's >>> probably practical to keep them around for a while, and just not include >>> them in the proposed updated API. Do you have a suggestion for what might >>> be a reasonable deprecation timeline? >> >> Awesome. >> >> Here is a rough plan of how deprecation could work: >> >> 0 months: Add a new extension format version and remove HTML >> notifications support with that version. >> 2 months: Support for the new format version is in Chrome's stable >> channel. The documentation advises the new format version, and new >> features require it. >> 4 months: We start requiring the new manifest version for new >> extensions uploaded to the store. >> 8 months: We start requiring the new manifest version for updates to >> existing extensions in the store. >> 10 months: Remove support for the old manifest version from trunk of >> Chrome. I believe at this point, we can remove the code from WebKit. >> >> We've never actually done this before though, so there may be some >> hiccups. I'd plan on about a year. >> >> We have already started a new manifest format version for Chrome 18, >> hopefully I can squeeze this change into that release. >> >> On Wed, Feb 8, 2012 at 9:24 PM, Adam Barth <[email protected]> wrote: >>> Unrelated to timeline, it might be worthwhile to make >>> createHTMLNotification a runtime-enabled feature so that we can avoid >>> offering it to the web at large and possibly restrict it to only a >>> whitelisted set of extensions. >> >> This is a very good idea. >> >> - a > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
