[webkit-dev] Deprecating JS interface

[Adam Barth]

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 this 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.

Adam