On Apr 29, 2012, at 1:18 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > On Sun, Apr 29, 2012 at 1:08 PM, Maciej Stachowiak <m...@apple.com> wrote: > On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >> On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak <m...@apple.com> wrote: >> >> On Apr 27, 2012, at 6:29 PM, Dirk Pranke <dpra...@chromium.org> wrote: >>>> BTW, the page at <https://trac.webkit.org/wiki/DeprecatingFeatures> seems >>>> to be using "deprecate" in the sense of "remove entirely". Is that what is >>>> meant? If so, I think it would be helpful to change the wording to >>>> "removing features". In non-Web contexts, deprecate often means a step >>>> short of removal. >>> I agree that "Removing features" is clearer and more to the point :). >>> When to deprecate features in the sense of "we recommend you use this >>> other feature instead" is an entirely different conversation. >> >> Now that I look closer, I see that it says: >> >> "Deprecating a feature means we will remove it in the future. Deprecation is >> not meant as a usage metric collection or to assess web-developers' >> reactions." >> >> This seems to imply that there actually is a step of deprecation that comes >> prior to removal. What exactly is this step? How are features supposed to be >> marked deprecated? What is the effect of being deprecated, if any, other >> than future removal? Does anyone who was at the session know the answer? >> >> I'd assume this is something like outputting a warning in the console. >> (Disclaimer: I didn't attend this session.) > > That sounds plausible, but I'm hoping to hear from someone who attended the > session to say for sure. If "deprecate" means console warning, followed by > removal later, then I'd suggest we go straight to removal. > > Outputting console warnings prior to a feature removal appears to be a common > practice (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=749920). I'm also > afraid that not giving any advance notice for features that have some users > like mutation events might be perceived badly by developers. > > On the other hand, I'm certain we don't need to output console warnings if > we're removing features nobody uses (e.g. support for khtml prefixes for > recently added CSS properties). > > So we probably can't (and shouldn't) make a unilateral policy here.
I agree that it's a good idea to give content authors due notice. But I don't think a console warning is a very good way to do it. I think most authors pay no attention to console spam. A blog post would probably reach more authors successfully than a console warning. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
