>>> 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.
I will make the change as people seem to prefer talking about removal than deprecation. >>> 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? This is unfortunately something that we didn't discuss much. Our current way is to display something on the console as Ryosuke pointed out, which is easy but likely not optimal. >> 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. I have one issue with that. First this proposal assumes that the feature is not exposed in someone's API. For such features, we will need to have a deprecation step as it needs to be removed from every vendors API. More to the point, deprecating gives us a safety net in case we missed something during our data gathering (an example I can think of are intranets or internal apps that may be using the feature). > 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. Seems like a good balance to give some leeway on whether we should have a deprecation step or not. Julien _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
