- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 9 Aug 2012 16:21:34 +0300
- To: Robin Berjon <robin@berjon.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Thu, Aug 9, 2012 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote: > Trying to evangelise that something is experimental is unlikely to succeed. But when trying out a new API people do look at the console a lot (you tend to have to :). It might be useful to emit a warning upon the first usage of an experimental interface, of the kind "You are using WormholeTeleportation which is an experimental API and may change radically at any time. You have been warned." IMO, this is just the wrong attitude to take to the problem. The problem is not that authors are unwisely using experimental features and we should pressure them not to. The problem is that authors are quite rationally using features that are useful in the real world, and some people are sad that this means we have to actually stop changing them once they're used. The solution is not to get authors to use shipped features less. You aren't going to convince authors to stop using useful features no matter how much you insist they're experimental. The solution is for implementers to consider all shipped features frozen until proven otherwise, and stop maintaining the pretense that widely-used features are experimental or changeable just because they're behind a vendor prefix. It would help a lot if implementers stopped shipping new prefixed features to stable channels. I believe Mozilla already intends to do that for CSS features, and I hope it does so for DOM features too. If a feature is really unstable, don't ship it to enough users that you're creating a compat burden on yourself.
Received on Thursday, 9 August 2012 13:22:22 UTC