On Feb 17, 2013, at 9:16 AM, Adam Barth <aba...@webkit.org> wrote: > On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze <dschu...@adobe.com> wrote: >> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak <m...@apple.com> wrote: >>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo <fpi...@apple.com> wrote: >>>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschu...@adobe.com> wrote: >>>>> The discussion on each single feature let us forget the greater scope of >>>>> this problem. That is why I did not start with a concrete example. >>>>> >>>>> What about going another direction? Right now we have compiler flags for >>>>> a lot of new features. What if we turn this around? Why not having a >>>>> compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk >>>>> to make sure deprecated features still work properly. Release builds >>>>> should turn it on to not break compatibility. But every binary build of a >>>>> nightly or preview has it turned off. A lot of developers experiment with >>>>> Chrome Canary and WebKit nightlies already. It might be a drop in the >>>>> bucket, but still can have some influence on decreasing the use of >>>>> deprecated content. Features like CSS gradients, transitions and >>>>> animations might be good candidates at the beginning for this flag. >>>> >>>> This carries the risk of decreasing test coverage of Nightlies and >>>> Canaries. I don't think that is acceptable. >>>> >>>> Users who download them and cannot use a web page because that page had >>>> deprecated features will then not be able to experience what bugs we had, >>>> those deprecated features notwithstanding. >>>> >>>> I empathize with the desire to remove cruft. But we shouldn't remove >>>> things if it breaks the web, even in Nightlies and Canaries. >>> >>> I agree with Phil. And as a corollary, if removing something *doesn't* >>> break the Web and we think it's otherwise bad, then there's no need to do a >>> special dance with nightlies before removing. >> >> Then we should face it. Prefixed content for CSS gradients, animation, >> transition, transforms, CSS Image functions, masking and a lot more will not >> go away. This basically means we will need to support them for an >> undetermined period of time, possibly for the projects lifetime. This will >> be the same for every popular prefixed feature that we introduce in the >> future. >> >> If we are honest about this we may can prevent future content to be a burden >> on maintenance and use similar concepts as Mozilla does with runtime flags >> on unprefixed features. > > Just because we want to be thoughtful about which features we > deprecate doesn't mean that we'll be unsuccessful in removing > vendor-prefixed features.
I really hope so. Right now it looks like we hope that the time will solve the problems that we introduced. I fear that this will not be the case for some popular prefixed features and requires a bit more of a push. See the 'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up with the worst case scenario that less reviewers are capable to estimate the influence of a patch. Greetings, Dirk [1] https://bugzilla.mozilla.org/show_bug.cgi?id=765645 > > Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
