On Mon, Mar 4, 2013 at 5:07 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Mon, Mar 4, 2013 at 5:01 PM, Jer Noble <jer.no...@apple.com> wrote: > >> >> On Mar 4, 2013, at 5:00 PM, James Robinson <jam...@google.com> wrote: >> >> On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble <jer.no...@apple.com> wrote: >> >>> >>> On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >>> >>> Could you add either build or runtime flag? >>> >>> >>> I most definitely could. But are there any ports who would disable the >>> flag? (Honestly asking, here.) If not, adding a feature flag may be more >>> trouble than its worth. >>> >> As everyone else has already stated, it's a good practice to wrap new > features behind a build flag so that we may disable the feature as needed. > e.g. your proposal needs to be modified > MAY need to be modified significantly. > significantly before it can be standardized. It'll be bad if browsers with > a faster release cycle (e.g. Chrome) ended up shipping this property while > such a discussion is taking place. > > The general rule of thumb is to have a build flag at least until the > specification reaches CR. > >> In chromium we would like the ability to monitor and, when appropriate, >> disable vendor-prefixed non-standard CSS properties. I think it's a bad >> idea to assume that by default all ports will want to expose non-standard >> API to the web platform without at least considering the situation and >> having a plan to remove at least the prefixed version. Please add a flag >> and, for bonus points, hook up FeatureObserver so we can monitor usage of >> this property. >> >> >> Sure thing. >> > > Thanks! > > - R. Niwa > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev