[webkit-dev] Maciej's prefixing questions (was Re: webkitPostMessage)

[Adam Barth]

On Sun, Apr 29, 2012 at 7:33 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> In the longer term, here's a few things we should think about:
>
> - Historically, we've almost never removed prefixed versions of features that get promoted to unprefixed. The marginal maintenance cost is low and there's usually some nonzero compat benefit. We have not usually considered benefit to the Web platform as a whole to be a major deciding factor. Should we change this assumption, and start removing prefixed versions of features more aggressively?

As WebKit becomes a more and more popular rendering engine, the cost
we impose on the platform and on other vendors by supporting
vendor-prefixed properties grows.

IMHO, we should be more agressive about removing prefixes.  There's
likely to be some compatibility cost, and there are also likely to be
some prefixes (like -webkit-transform) where the cost of removal is
too high.  I suspect different consumers of WebKit view these
trade-offs differently, which might make it more difficult to make a
project-wide decision on these issues.

> - Does prefixing work well for JavaScript APIs (as opposed to CSS properties)? For whatever reason it seems more disruptive.

My sense is that prefixing works better for CSS properties.  There are
a couple reasons that come to mind:

1) The CSS working group has set out clear guidelines about when it's
appropriate to use vendor prefixes (i.e., prior to CR).
2) It's easy for authors to spam their CSS with vendor prefixes,
especially when using a system like SASS.

> What should be our approach to adding prefixed JS APIs, and at what point should we promote them to unprefixed?

That's a tough question.  Using a vendor prefix makes it easier to
innovate without constraining the future standardization process
(e.g., as is happening now with Notifications).  On the other hand,
the longer we support prefixed APIs, the more likely those APIs are to
get "stuck" and cause interoperability problems for other vendors.

The "worse is better" solution is for every vendor to implement the
prefixes of the popular vendors, similar to what has happened to the
User-Agent string and what's happening today with some CSS properties.
 Maybe that's where we'll end up.

Adam