On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <[email protected]> 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 participants about WebKit shipping half-baked implementations and >> breaking feature-detection. >> >> As an example, when WebKit enabled new types for form controls, we didn't >> initially have useful UIs. This resulted in breaking websites that relied on >> feature-detection to decide whether to use new types or fallback to JS-based >> fallback UI. Now those websites need to rely on navigator string. (I don't >> intend to name-call anyone or blame this instance in particular). >> >> So when is a Web-facing feature implemented in WebKit good enough to be >> enabled by any port? Should there be some set of criteria to be met? > > 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 same > time present but non-functional in Chrome). > > I think in the past, port owners have made clear that they want to own the > final decisions on what features are enabled in their ports. > > But we as a community could do better, by having a shared recommendation of > what features we think should be enabled in shipping releases. In some cases, > this may not match the settings on trunk, as some features may be desirable > to enable for experimental builds, but not in shipping product. For features > that we recommended disabling, ideally we'd identify a reason. And in some > cases, those might be port-specific issues. > > Would other port owners find such a list useful? Is anyone else willing to > help maintain it? I think a good place to keep it would be in WebKit SVN, and > we should treat it as if it was shared cross-platform code, which means > anything in the list would require community consensus, not port-specific > decisions. In some cases, we may have a hard time coming to agreement, in > which case the default should probably be no recommendation either way. > > For features that we recommend for all ports and that do not have port > specific issues, we might even consider removing the ENABLE flag.
One idea we've kicked around is to replace the binary on/off flags for features (e.g., in features.gypi for the Chromium port) with something like off/nightly/beta/stable. That way folks can think about whether they want to enable features for nightly, beta, or stable builds on a given port. This mechanism also gives the community a better sense for the perceived maturity of each feature. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
