On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschu...@adobe.com> wrote:
> > 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 th i > 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@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
