Re: Intent to ship: Element.animate

2016-04-19 Thread bbirtles
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

2016-04-18 Thread bbirtles
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