Re: Intent to ship: Element.animate
On Tuesday, 19 April 2016 22:03:48 UTC+9, smaug wrote: > > This is a temporary situation because I don't want to have to back out the > > whole Element.animate feature due to compat issues from the 'Animation' > > interface name. After we have shipped Element.animate we can ship the > > Animation constructor behind a different pref. > Why would you need to backout animate() if the interface was > [NoInterfaceObject] ? This was referring to the alternative of shipping the constructor under the same pref as the rest of the Element.animate implementation. If we do that and compatibility issues with 'Animation' arise late in the game, we'd have to turn off the pref and effectively unship the whole Element.animate feature. > So could we ship constructor + removing [NoInterfaceObject] as a separate > step, not when shipping this initial API? And have [NoInterfaceObject] until > that. If we're worried about web-compatibility, the API spec editors should > consider changing the spec to be more likely web-compatible, and better to > do that before anyone supports the constructor (since I assume it might mean > changing the interface name) We could, however we have quite a few tests that rely on this constructor so we'd end up being unable to test a lot of things. I wouldn't want to make it [NoInterfaceObject] on trunk, at least, but perhaps we could do that on aurora/beta, for example. If we do discover compatibility issues, I'll gladly update the spec. And just to clarify, there are no specific compatibility issues that I am aware of--just the fact the Animation is a fairly generic name. At this point it seems like it depends on how likely we are to hit compatibility issues. I'll see if the blink folks have any data on this. If it seems like the compatibility risk is low, then we should just ship the constructor from the start and take the risk that we might have to disable Element.animate. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Element.animate
On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote: > On 04/18/2016 05:12 AM, Brian Birtles wrote: > > In Firefox 48 I intend to turn Element.animate on by default. > > > > We have been developing the Web Animations API behind the > > dom.animations-api.core.enabled preference and have introduced the > > dom.animations-api.element-api.enabled preference for the subset of the API > > that we intend to ship at this time. > > > > Chrome have been shipping a very similar subset of the API starting with > > Chrome 36[1] and have recently updated their implementation to match the > > subset we plan to ship.[2] > > > > WebKit[3] and Edge[4] both list this as "under consideration" although some > > implementation work has begun in WebKit.[5] > > > > This feature was previously discussed in this "intent to implement" thread: > > https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion > > > > Bug to turn on by default: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1245000 > > Link to standard: > > https://w3c.github.io/web-animations/#dom-animatable-animate > > > > The subset of the API we intend to ship is described in the bug above, a > > summary of which I have copied to the end of this mail. We do not intend to > > ship the 'finished' promise at this time due to concern that this should > > use a cancelable promise.[6] > > Does blink ship 'finished' promise? No. I've just discussed with them and we will also not ship the 'ready' promise either, for similar reasons. > Are there good wpt tests where we pass the same tests as other implementers? Yes. We've contributed a number of tests to wpt and the Chrome team are running them against blink and addressing issues that arise. We still have more tests to contribute though and a few of us are spending a lot of time on that at the moment. > > // 'Animation' will not be exposed on the global unless Element.animate is > > called > What does this mean? Per spec 'Animation' should be exposed in the global. Full details are in bug 1245000 from comment 9 onwards (https://bugzilla.mozilla.org/show_bug.cgi?id=). Initially we would like to release Animation as [NoInterfaceObject] because of compat concerns that other libraries might be using 'Animation'. Blink currently ships with [NoInterfaceObject] so we don't know yet if this interface name is Web compatible. (Unlike blink, however, we have implemented the Animation constructor and, per-spec, implemented Element.animate() in terms of that constructor. Hence the slightly odd situation where Animation is not initially on the global but might be added if you call Element.animate().) This is a temporary situation because I don't want to have to back out the whole Element.animate feature due to compat issues from the 'Animation' interface name. After we have shipped Element.animate we can ship the Animation constructor behind a different pref. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
