Hi. What status should be used for: "Enabled by default on most platforms except those we’ve decided not to support or if a local system dependency can’t be met but feature is still ready for general use, but UI to toggle the feature remains to support debugging, A/B testing."
That defaultValue could be ignored in the future seems a regression and doesn’t address some existing use cases. Thanks Jean-Yves > On 10 Jan 2023, at 9:11 am, Elliott Williams via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
