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.

Greetings,
Dirk
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to