On 04/19/2016 04:03 PM, smaug wrote:
On 04/19/2016 03:29 AM, [email protected] wrote:
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().)
That doesn't sound like a behavior we should ship. Either make it
[NoInterfaceObject] or normal interface.
And if it needs to be [NoInterfaceObject], constructor shouldn't be supported.
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] ?
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)
In other words, ok to ship from here, but not with the odd [NoInterfaceObject]
+ constructor setup.
-Olli
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
