On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze <dschu...@adobe.com> wrote: > On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak <m...@apple.com> wrote: >> On Feb 16, 2013, at 10:16 PM, Dirk Schulze <dschu...@adobe.com> wrote: >>> On Feb 16, 2013, at 6:54 PM, Adam Barth <aba...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
