[webkit-dev] Deprecating JS interface

Sun Feb 17 01:09:13 PST 2013

On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschulze at adobe.com> wrote:

> 
> On Feb 17, 2013, at 12:08 AM, Adam Barth <abarth at webkit.org> wrote:
> 
>> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>>>>> On Feb 16, 2013, at 6:54 PM, Adam Barth <abarth at webkit.org> wrote:
>>>>> 
>>>>>> It's much easier to discuss a concrete example.  Which interface are
>>>>>> you interested in deprecating?
>>>>> 
>>>>> I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point.
>>>>> 
>>>>> A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it.
>>>> 
>>>> Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here.
>>> 
>>> It is a proposal so far and no draft yet. Technically, I am not the editor of it so. The proposal has quite some way to go (hopefully not too much) and I do not plan to land anything in this direction as long as the responsible WGs did not agree on continuing with the proposal and the general direction. I will post a separate mail with the actual feature implementation announcement when the time comes.
>>> 
>>>> Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class.
>>> 
>>> I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. I got an action of the SVG WG to work on a replacement for SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix (which is definitely actively used by web content) and provide a basic interface that can be used beyond just SVG. There are a lot of use cases in the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious once. A specification interoperable format to share transformation data seems extremely desirable. I encourage everyone who is interested to look at the proposal and give feedback.
>>> 
>>>> 
>>>>> 
>>>>> Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future.
>>>> 
>>>> I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it.
>>> 
>>> I agree that we need more metrics to discuss the next active steps on WebKitCSSMatrix and I already uploaded a patch to add it to the FeatureObserver[1].
>>> 
>>> The question remains: How do we want to continue with deprecating WebKit specific features in the long term. Especially when we have a standard compliant replacement. It is extremely hard to maintain all different behaviors. So far we have multiple implementations of background, flex-box, gradients to name some. This doesn't scale very well and there will be a time where we can not guarantee for the correct functioning of old features. This is a problem that other browsers like IE are focused for quite some time as well (not necessarily successfully). As long as we are concerned to deprecate and remove features, we increase the complexity of the code base. Less and less reviewers will be able to determine the behavior of patches to the general code base, while we increase the feature count and interoperability between modules more and more. There is no other way then to risk breaking content that relies on non-standardized behavior of platforms. And we should formalize thi
> s
>> to give a bit more reliability to web authors. The last section on [2] is too vague at the moment.
>> 
>> I don't think we're be successful at formalizing a general approach at
>> this time.  Instead, we should consider each case in turn and use our
>> best judgement.  If a pattern emerges over time, we might want to
>> document that pattern in
>> http://trac.webkit.org/wiki/DeprecatingFeatures.
>> 
>> At the moment, deprecating WebKitCSSMatrix seems premature as there
>> isn't yet a suitable replacement.
> 
> 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.

-F

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