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



_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to