> On Nov 5, 2016, at 6:13 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > Hi, > > We discovered that several experimental features are currently enabled > by default: > > https://bugs.webkit.org/show_bug.cgi?id=164367 > ... > These features are not ready to be default, or they wouldn't be listed as > experimental.
This has come up in Apple, where some people assume that the fact they're called "Experimental" features means they are still under heavy development or in some way unstable or potentially harmful. I don't believe that is actually the case. Ignoring the name for a moment, the _WKExperimentalFeature API really does precisely two things: 1 - Exposes an enumerable set of runtime-enablable features. 2 - Exposes an API to turn each of them on or off. That's it. For a long time we've had "runtime enabled features" in the project with no way to expose them as an enumerable set to the API client. The API was named "Experimental" feature, I think, because at first only "under heavy development" features that were not ready to be enabled at runtime adopted the mechanism. I think the API wasn't named properly for how it was destined to be used, as there was a clear need for an API that presents many "non-experimental" runtime enabled features to the client. But in reality, many other long standing runtime-enabled features could (and in my opinion *should*) be under the same mechanism. I know some engineers have expressed the opinion that once a runtime feature is stable enough to be turned on by default then it should no longer be "experimental" and should be removed from the set of experimental features. But other engineers (myself included) see this set of features as "an enumerable list of runtime features that can easily be turned on and off" Whether or not a feature is on by default, there is significant value in having this enumerable list of runtime features. A feature might be deemed stable enough to enabled by default but it's extremely useful for a user to quickly be able to *disable* it at runtime to see if it has broken a website, or for a dev to quickly and easily test site behavior with it enabled or disabled. Additionally, it commonly makes sense for a feature to be enabled by default in WebKit trunk but then *disabled* by default in a branch. > They should be enabled by Safari if they're desired there. The ones that have been deemed fit to be "enabled by default" for testing should be on by default for testing in places other than Safari, such as MiniBrowser and 3rd party WebKit apps. > It looks like the change was made to avoid needing to enable the > features manually in Safari Tech Preview, but of course this is bad for > all the non-Safari WebKit ports which surely do not want experimental > features enabled by default. As mentioned above, it's not only Safari that wants these on by default. However, I definitely agree that different ports have different concerns - e.g. What Apple might want enabled by default in its port, GTK might not. > Can we fix the WebKit project defaults please? I strongly object to reverting all _WKExperimentalFeatures to "off by default" I strong support adding port-specific defaults. As a different conversation, I also support renaming the API to something that doesn't impart the baggage of an "under development" or "unstable" feature. Thanks, ~Brady
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
