[webkit-dev] Enabling new features in WebKit + prefixing

[Dean Jackson]

This is a brief summary of yesterday's discussion at the contributors' meeting. If there is no strong disagreement here then I'll add this to the wiki.

New Features
------------

- The rule of sending an email to webkit-dev when you're about to start work on a new feature remains in place. The idea here is that the community can support or object to the feature even being in the tree.

- Once the implementation of the feature is ready for use, send another email to webkit-dev announcing your intentions to enable the feature in nightly builds. How do you know when something is "ready for use"?

  + You want external developers to play with it and provide feedback (either to WebKit or a standards body)
  + Bugs and (some) crashes are ok, although it would be great if they were minimised.
  + Security and privacy issues are **NOT** ok. e.g. if the specification describes a security issue with no known solution, or if the known solution has not yet been implemented, then the feature should not be enabled.

If there is general agreement on the list then go ahead and enable the feature for nightlies. Port owners now have the responsibility to disable it for their shipping branches.

- If you're in a middle ground then you may consider enabling the feature for compilation, but protecting it behind a runtime flag that is disabled by default. Again, you should send an email to webkit-dev announcing this. An example of this would be a feature where security issues have been suggested but not confirmed.


Prefixing
---------

- We still recommend prefixing on most new features while they are unstable. e.g. CSS properties and property values, if necessary. This is different from the Blink and Mozilla approach (which is to not prefix).

- We will now avoid prefixing on our file names. e.g. WebKitCSSMatrix should be just CSSMatrix. This might need some changes in the binding generators.

- If possible, prefer no prefixing in IDL and event names. Of course, for a truly new Web-exposed feature, this might be impossible.


Unprefixing
-----------

- We want to unprefix things as soon as we can. This relates back to the stability point above, which is hard to determine. Blink are trying to track stability here -> [1].

- We think there are many things in WebKit that can now be unprefixed. Alexis did a great job unprefixing CSS transitions - follow his lead.

- We will continue to support the prefixed properties for some amount of time, decided on a case-by-case basis.

[1] http://www.chromestatus.com/features