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. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
