Hi webkit-dev,

Brent (CC’d) and I are rolling out changes to how we represent feature flags in 
WebKit. As of https://commits.webkit.org/258448@main, the WebPreferences*.yaml 
files have been merged to one feature list:

        Source/WTF/Preferences/UnifiedWebPreferences.yaml

Instead of having separate lists of experimental features, internal debug 
features, etc., each feature now has a `status` field. A feature’s status 
determines which UIs it is visible in (if any), and in the future will control 
its default value. Right now, these are the semantic meanings of the features 
status:

        embedder        Adjust WebKit behavior for embedding application needs.
        unstable        Feature in active development. Unfinished, no promise 
it is usable or safe.
        internal        Tools for debugging the WebKit engine. Not generally 
useful to web developers.
        developer       Tools for web developers.
        testable        Enabled by default in test infrastructure, but not 
ready to ship yet. Should be accessible for STP users who wish to activate them 
for testing and feedback.
        preview Enabled by default in Safari Technology Preview, but not 
considered ready to ship yet.
        stable  Enabled by default and ready for general use, but UI to toggle 
the feature remains to support debugging, A/B testing.
        shipping        Enabled by default and ready for general use, but no UI 
to toggle. In general, will be removed 1 year after the change to shipping.

When you’re adding or changing features, our source generator will force you to 
pick one of these status. The “public-facing” statuses (developer, testable, 
preview, stable) are visible from the various “experimental features” call 
sites declared by WebKit, and the rest are exposed as “internal debug 
features”. And I’m adding an additional WebPreferences API which lists all 
features, so clients can avoid the experimental/internal-debug dichotomy going 
forward.

There’s one topic I’d like feedback on, which pertains to the non-Apple ports:

Some features don’t seem to have the same “status” on all platforms. For 
example, pdf.js has been enabled for GTK and WPE for some time now, and should 
probably be considered `stable` on those platforms. But it’s off by default on 
Apple platforms, where it should be no more than `testable`. How do we resolve 
discrepancies like these? We could:

- allow a feature’s status to be platform-conditional
- allow each port to decide whether a feature is on or off by default 
(regardless of its status)
- do nothing, and require clients to change feature statuses at runtime in 
order to modify default behavior

I’d like to eventually use the committed feature list to power 
https://webkit.org/status/, which makes me want to avoid having 
platform-conditional statuses. It would also be nice for feature statuses to be 
a global truth, helping us speak collectively about what web platform features 
are supported.

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

Reply via email to