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 global view of who's using what (and ideally why?). -eric On Mon, Feb 13, 2012 at 3:13 PM, Adam Barth <[email protected]> wrote: > 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
