On Feb 17, 2013, at 12:08 AM, Adam Barth <aba...@webkit.org> wrote: > 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 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. Greetings, Dirk > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
