On Tue, Aug 14, 2012 at 11:56 AM, Julien Chaffraix < julien.chaffr...@gmail.com> wrote:
> > 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 a runtime flag incurs runtime cost. > Having tons of #ifdef's is a lot more worrying from my perspective, Having a runtime flag is significantly worse in that it affects end users. Having a compile flag is a painful for developers but has absolutely zero cost for end users. > * 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. > I had certainly assumed that this was done under a new build flag. If that were not the case, I expected relevant reviewers to r- those patches. Maybe this was a bad assumption to make. 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. I strongly object to implementing this feature behind a setting. It should be developed under a build flag. - Ryosuke
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
