I made https://trac.webkit.org/wiki/FeatureFlags .
I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments.
Feel free to edit it!
On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent tk...@chromium.org wrote:
I'll add a Wiki page for the table of existing feature flags and their
Great. Thanks!
On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent tk...@chromium.org wrote:
I made https://trac.webkit.org/wiki/FeatureFlags .
I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments.
Feel free to edit it!
On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent
By the way, can we add a point of contact for each one of these features? I
often find it hard to figure out who owns which feature/flag.
- Ryosuke
On Thu, Mar 15, 2012 at 11:51 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. Thanks!
On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent
On Mon, Feb 13, 2012 at 11:09 PM, Maciej Stachowiak m...@apple.com wrote:
I think we're talking about a couple of different things now:
1) Table of what the WebKit community as a whole (instead of individual point
maintainers) thinks should be enabled in stable releases. This would be input
I'll add a Wiki page for the table of existing feature flags and their
descriptions.
On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak m...@apple.com wrote:
I think we're talking about a couple of different things now:
1) Table of what the WebKit community as a whole (instead of individual
On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote:
Hi all,
In general, the decision of whether a given feature is enabled or not is made
by each port. However, at last year's W3C TPAC, there were complaints from
other participants about WebKit shipping half-baked implementations and
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
I think you raise a good point. Another point worth mentioning is that
sometimes a feature can be complete and useful in one port, but half-baked
in another (for example, fullscreen API was shipped in Safari and at the
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote:
Hi all,
In general, the decision of whether a given feature is enabled or not is
made by each port. However, at last year's W3C TPAC, there were complaints
from other
Related to this is the question of what ports are even on for various ports.
I don't believe it's possible today to list what features are on for
what ports. At least not without a lot of emailing...
Before designing a finer-granularity on/off switch, it seems it might
make sense to have a
On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
I think you raise a good point. Another point worth mentioning is that
sometimes a feature can be complete and useful in one port, but half-baked in
another (for
(Re-sending from the right address...)
I'd +1 Adam's point.
It would be great if we can do something like webkit-build --gtk
--stable, webkit-build --chromium --canary or webkit-build
--nightly where the script read the central configuration file and
find an appropriate configuration. In this
I think we're talking about a couple of different things now:
1) Table of what the WebKit community as a whole (instead of individual point
maintainers) thinks should be enabled in stable releases. This would be input
to port maintainers looking to make a release.
2) Documenting what enable
On Tue, Feb 14, 2012 at 11:09 AM, Maciej Stachowiak m...@apple.com wrote:
I think we're talking about a couple of different things now:
1) Table of what the WebKit community as a whole (instead of individual point
maintainers) thinks should be enabled in stable releases. This would be input
Hi all,
In general, the decision of whether a given feature is enabled or not is
made by each port. However, at last year's W3C TPAC, there were complaints
from other participants about WebKit shipping half-baked implementations
and breaking feature-detection.
As an example, when WebKit enabled
14 matches
Mail list logo
