[webkit-dev] Deprecating JS interface

[Adam Barth]

On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze <dschulze at adobe.com> wrote:
> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo <fpizlo at apple.com> wrote:
>>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschulze at 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