[webkit-dev] Deprecating features guideline wiki

[Dirk Pranke]

On Fri, Apr 27, 2012 at 5:17 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> I think the concern is that, due to lack of clear standards, we end up not knowing when we can remove things. Thus, we end up with a lot of inconclusive and frustrating conversations, and people may shy away from even trying to remove things.
>

My concern is to clarify our stance is on removing features with
vendor prefixes once the non-prefixed version has been implemented.
That is a subset of the general "when can we remove a feature after
we've shipped it" problem.

Reading Julien's summary, it sounds like the stance for webkit will be
"we won't (and shouldn't) remove a feature unless it is causing us
(webkit devs) enough pain that it would justify potentially breaking
pages".

Obviously, some people believe that this is not how vendor prefixes
are supposed to work; that we are supposed to remove support for
vendor prefixed features at some near-ish time after the unprefixed
version has shipped.

At the very least, by not being clear about what our process is, we
make it very hard for the html teachers of the world (evangelists,
book authors, etc.) to convey an accurate message to their audience,
and we risk misleading html authors as well.

> 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.

-- Dirk