Re: [webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 17, 2013, at 3:02 PM, Dirk Schulze  wrote:

> 
> On Feb 17, 2013, at 9:16 AM, Adam Barth  wrote:
> 
>> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>>> 
>>> Then we should face it. Prefixed content for CSS gradients, animation, 
>>> transition, transforms, CSS Image functions, masking and a lot more will 
>>> not go away. This basically means we will need to support them for an 
>>> undetermined period of time, possibly for the projects lifetime. This will 
>>> be the same for every popular prefixed feature that we introduce in the 
>>> future.
>>> 
>>> If we are honest about this we may can prevent future content to be a 
>>> burden on maintenance and use similar concepts as Mozilla does with runtime 
>>> flags on unprefixed features.
>> 
>> Just because we want to be thoughtful about which features we
>> deprecate doesn't mean that we'll be unsuccessful in removing
>> vendor-prefixed features.
> 
> I really hope so. Right now it looks like we hope that the time will solve 
> the problems that we introduced. I fear that this will not be the case for 
> some popular prefixed features and requires a bit more of a push. See the 
> 'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up 
> with the worst case scenario that less reviewers are capable to estimate the 
> influence of a patch.

We've successfully removed prefixed versions of features before. It will 
probably be harder for transitions and transforms than for some other things, 
but perhaps not impossible. The first step is getting to a point where we have 
a non-prefixed alternative, as  
does for transitions for instance.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 9:16 AM, Adam Barth  wrote:

> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:
>>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
 On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
> 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.
>>> 
>>> I agree with Phil. And as a corollary, if removing something *doesn't* 
>>> break the Web and we think it's otherwise bad, then there's no need to do a 
>>> special dance with nightlies before removing.
>> 
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> Just because we want to be thoughtful about which features we
> deprecate doesn't mean that we'll be unsuccessful in removing
> vendor-prefixed features.

I really hope so. Right now it looks like we hope that the time will solve the 
problems that we introduced. I fear that this will not be the case for some 
popular prefixed features and requires a bit more of a push. See the 
'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up 
with the worst case scenario that less reviewers are capable to estimate the 
influence of a patch.

Greetings,
Dirk

[1]  https://bugzilla.mozilla.org/show_bug.cgi?id=765645

> 
> Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 2:47 PM, Ryosuke Niwa  wrote:

>> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> This is why we need to be extremely careful when introducing new features. 

I absolutely agree.  Chrome introduced the runtime flags as one possible 
solution for this problem.

Greetings,
Dirk

> 
> - R. Niwa
> 
> ___
> 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

Re: [webkit-dev] Deprecating JS interface

[Ryosuke Niwa]

On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:

> Then we should face it. Prefixed content for CSS gradients, animation,
> transition, transforms, CSS Image functions, masking and a lot more will
> not go away. This basically means we will need to support them for an
> undetermined period of time, possibly for the projects lifetime. This will
> be the same for every popular prefixed feature that we introduce in the
> future.
>
> If we are honest about this we may can prevent future content to be a
> burden on maintenance and use similar concepts as Mozilla does with runtime
> flags on unprefixed features.
>

This is why we need to be extremely careful when introducing new features.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Adam Barth]

On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:
>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
>>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
 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.
>>
>> I agree with Phil. And as a corollary, if removing something *doesn't* break 
>> the Web and we think it's otherwise bad, then there's no need to do a 
>> special dance with nightlies before removing.
>
> Then we should face it. Prefixed content for CSS gradients, animation, 
> transition, transforms, CSS Image functions, masking and a lot more will not 
> go away. This basically means we will need to support them for an 
> undetermined period of time, possibly for the projects lifetime. This will be 
> the same for every popular prefixed feature that we introduce in the future.
>
> If we are honest about this we may can prevent future content to be a burden 
> on maintenance and use similar concepts as Mozilla does with runtime flags on 
> unprefixed features.

Just because we want to be thoughtful about which features we
deprecate doesn't mean that we'll be unsuccessful in removing
vendor-prefixed features.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:

> 
> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
> 
>> 
>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
>> 
>>> 
>>> 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.
> 
> I agree with Phil. And as a corollary, if removing something *doesn't* break 
> the Web and we think it's otherwise bad, then there's no need to do a special 
> dance with nightlies before removing.

Then we should face it. Prefixed content for CSS gradients, animation, 
transition, transforms, CSS Image functions, masking and a lot more will not go 
away. This basically means we will need to support them for an undetermined 
period of time, possibly for the projects lifetime. This will be the same for 
every popular prefixed feature that we introduce in the future.

If we are honest about this we may can prevent future content to be a burden on 
maintenance and use similar concepts as Mozilla does with runtime flags on 
unprefixed features.

Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:

> 
> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
> 
>> 
>> 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.

I agree with Phil. And as a corollary, if removing something *doesn't* break 
the Web and we think it's otherwise bad, then there's no need to do a special 
dance with nightlies before removing.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Filip Pizlo]

On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:

> 
> On Feb 17, 2013, at 12:08 AM, Adam Barth  wrote:
> 
>> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
>>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
 On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
> On Feb 16, 2013, at 6:54 PM, Adam Barth  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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 12:08 AM, Adam Barth  wrote:

> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
>>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
 On Feb 16, 2013, at 6:54 PM, Adam Barth  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 com

Re: [webkit-dev] Deprecating JS interface

[Adam Barth]

On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
>>> On Feb 16, 2013, at 6:54 PM, Adam Barth  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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:

> 
> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
> 
>> 
>> On Feb 16, 2013, at 6:54 PM, Adam Barth  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 t
 o give a bit more reliability to web authors. The last section on [2] is too 
vague at the moment.

Greetings,
Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=110002
[2] http://trac.webkit.org/wiki/DeprecatingFeatures


> 
> Regards,
> Maciej
> 
> ___
> 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

Re: [webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:

> 
> On Feb 16, 2013, at 6:54 PM, Adam Barth  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.

Then we have a much simper transition story, and WebKitCSSMatrix can be aliased 
to the new class.

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

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 16, 2013, at 6:54 PM, Adam Barth  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.

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.

Greetings,
Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=110048
[2] https://bugs.webkit.org/show_bug.cgi?id=110001
> 
> Adam
> 
> 
> On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze  wrote:
>> Hi,
>> 
>> There are several steps on deprecating features[1]. My question is about 
>> deprecating a whole interface and throwing warnings that the feature is 
>> deprecated.
>> 
>> If I have the following interface for deprecation:
>> 
>> [Constructor]
>> interface Bla {
>>attribute bar;
>>void foo();
>> }
>> 
>> Should I just throw the deprecation warning on calling the constructor (and 
>> any method/attribute creating the object), or on calling foo and bar as well?
>> 
>> Greetings,
>> Dirk
>> 
>> [1] http://trac.webkit.org/wiki/DeprecatingFeatures
>> ___
>> 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

Re: [webkit-dev] Deprecating JS interface

[Adam Barth]

It's much easier to discuss a concrete example.  Which interface are
you interested in deprecating?

Adam


On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze  wrote:
> Hi,
>
> There are several steps on deprecating features[1]. My question is about 
> deprecating a whole interface and throwing warnings that the feature is 
> deprecated.
>
> If I have the following interface for deprecation:
>
> [Constructor]
> interface Bla {
> attribute bar;
> void foo();
> }
>
> Should I just throw the deprecation warning on calling the constructor (and 
> any method/attribute creating the object), or on calling foo and bar as well?
>
> Greetings,
> Dirk
>
> [1] http://trac.webkit.org/wiki/DeprecatingFeatures
> ___
> 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