> I don't think it's appropriate to add settings for CSS features that are > under development, > for a number of reasons: > > * If we did this for every feature, we'd end up with hundreds of Settings. > * Traditionally, Settings don't tend to get removed, resulting in an > ever-accumulating number of Settings.
ENABLE has a slightly better track of record but I don't think we should push back on runtime flags just because of that. Having tons of #ifdef's is a lot more worrying from my perspective, on top of not being able to build / test the feature before you toggle the flag on one platform (with all the surprises coming from platform differences when a port maintainer decide to do so). > * If your feature is protected by an ENABLE flag, vendors that want to ship > release software can turn it off. That's true, except that the original thread didn't mention any form of feature flag [1]. Nobody objected at the time and thus patches that implemented part of the spec arrived on bugzilla: prefixed but not protected by any flag. Due to the bar to landing such a change and exposing directly, I requested that a feature flag be introduced so that patches could be split into atomic pieces that can be reviewed one at a time (and also checking that the testing is appropriate). This update isn't about bringing a discussion about ENABLE vs runtime, more about mentioning that there will be a new flag contrary to what was said previously. There is definitely a trend to use runtime flags on core features lately (region, grid, custom filters...) sometimes along with ENABLE flags. This should be discussed separately. Thanks, Julien [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
