Hi Dean,
Thank you very much for this feedback. I agree with most of it. Other
parts I've taken on board and proposed how we can address your concerns.
However, some parts I don't think I've quite understood so please allow
me to respond inline.
(2012/12/01 4:59), Dean Jackson wrote:
> A. No use cases.
> ================
>
> A major contributing factor to high-level concerns is that the proposal doesn't
> list any use cases, requirements, goals, hopes, dreams or ambitions. Instead,
> it jumps right into the technical details. This is a very large proposal (more
> on that below) - it's essential to list out the use cases so they can be
> prioritised.
This is one of the items on which I'd like some clarification. Do you
mean you expect a list of use cases at the top of the spec? I notice,
for example, that CSS Animations does not have such a list so I'm not
sure why it is expected here.
There is some discussion of the motivations for the specification in the
Introduction section (particularly the 'Relationship to other
specifications' section). Would you prefer we extend this section? There
have also been offers to write a primer. Would that help?
Alternatively we could add annotations to the interface members to
describe the particular use cases where they are needed? These
annotations would appear in the ED only. What do you think?
Of course, if the suggestion is that there really are no use cases, then
we have documented a few general uses cases elsewhere[1]. In addition to
those, other features are based on, for example, experience with
Raphael, Mozilla bug reports, and the Parapara animation workshops.[2]
One particularly important use case (which admittedly is not documented
anywhere) that has influenced the design is the desire to be able to
debug animations. That is, it should be possible, using the API, to
write a tool that produces a timeline view of all active animations (and
in some cases past animations) in the document regardless of the markup
used to create them. Would you prefer this sort of thing go in the
introduction?
> B. Declarative Solutions.
> =========================
>
> We strongly think that any proposal for richer animations in HTML should be
> accompanied by a declarative form. It's nice that this proposal provides a
> powerful technology for scripting, but our primary audience should be people
> who write markup.
I strongly agree and, having discussed this with others this morning,
everyone involved is on the same page. We're going to push hard to get
the CSS spec moving along. The SVG spec will lag a little (simply due to
limited personpower) but it should be easier.
> Timesheets are a pretty good solution to this. They can be easily linked from
> an HTML doc. They separate timing from content. They are easy to author. They
> support nested timelines, plus parallel and sequential timing. However, they
> are based on SMIL so could possibly be infected with the curse. Other options
> would be to create a new format (JSON, CSS- or HTML-based?) or propose changes
> to HTML directly.
I agree about timesheets as a concept.
We've discussed this in the group before and we want to support that
style of usage. That is largely where the templates feature came from
(which I'll address later).
SMIL timesheets themselves introduce other complexity that we don't
think is necessary. Some of the ideas we've floated for combining CSS
and SVG syntax (similar to Filter Effects) would give you the same result.
> This is also related to the simplicity request in section C below. Timesheets
> will not provide powerful interactive content, but neither did CSS Animations
> and it didn't hinder adoption. Being able to write a document that does things
> at particular times without going to script will likely be praised by the
> community. Think slideshows, presentations, tutorials, etc.
Making slideshows work without any script would mean you need
declarative triggers. We've discussed adding that to the model but
decided not to address it in version 1.
For now, the easiest route for achieving that would be to expose what is
already available in SVG to HTML. If we can tidy up the SVG model and
improve interop with CSS through this work then that might become a more
attractive option.
(You can already target HTML with SVG animations in Gecko. If recent
efforts to allow using SVG more directly in HTML come to fruition this
becomes even simpler.)
> One very important use case to us is read-along in digital books - where words
> on the page are highlighted as an audio track speaks the story. EBook authors
> are not scripters. They need a fully declaritive solution, which ties to
> point D.1 below about separation of timing from animation. These elements are
> not animating as such, they are just changing state at particular times.
I've responded to this below.
> We realise that the proposal explicitly avoided declarative formats, suggesting
> that it forms the basis of a declarative technology, but we strongly believe
> the two need to be done at once. In fact, we think that a simple, author-
> friendly declarative format is more important to the Web than the API and
> should be a higher priority.
I agree about the importance of declarative approaches. I think of
higher importance still is the underlying model. The API is just a way
of expressing the model in concrete and testable terms and that is why
we have described it first, not because we believe it is, of itself,
more important.
> C. Overall size.
> ================
>
> This proposal is *WAY* too big for a 1.0 release. The supporting model is fine,
> but we object to exposing this much Web-facing API in a first release (again,
> without use cases, etc).
Firstly, by big are you primarily concerned about the number of
features, or the number of interface members, or simply the length of
the document?
Regarding the number of features, I agree. I am maintaining a list of
features I'd like to drop from v1 and have already started removing some
from the specification already.[3] Templates is on the list. More on
that below. (Also, there are plenty of other requested features like
adaptive duration and state machines that we deferred before even adding
to the spec so we've been showing restraint along the way.)
Regarding the number of interface members, this is largely based on the
debugger use case. We believe it should be possible to produce a
timeline view of the animations in the document using only the API and
that requires exposing certain state. Nevertheless I think it would be a
useful exercise to go through each member and annotate it with the use
case it is needed for and then see what we can drop. I've been doing
that informally and added a few members to my list of items to drop
mentioned above.[3]
Regarding the length of the document, we are trying to make explicit
much of what is underspecified in SVG and CSS in a way that promotes
interoperability. Our experience with developing a prototype polyfill
for this specification shows the implementation size is modest.[4]
> And there isn't really a need for everything at once -- CSS Transitions were
> adopted extremely quickly compared to other Web features primarily because they
> were so small and simple. We should start small, with only the features that we
> think are absolutely necessary, and then iterate from there. To give an example
> from the proposal that isn't necessary in 1.0: templates. It seems hard to
> justify these as necessary. There are many other similar things that could be
> cut for now.
As I mentioned, templates is something I've proposed dropping as well.
We discussed this at our meeting this morning and we may remove it from
v1 after we've investigated it further.
Templates possibly seem quite unnecessary but they arose as a means of
representing the relationship between markup and Animation objects. For
example an <animate> element in SVG is not itself an Animation object
but produces several Animation objects.
This interaction between markup and Animations becomes particularly
important when you have complex markup such as timesheets.
By adding templates to the API:
- The interactions between markup and Animations/AnimationGroups can be
defined in a way that is easily testable and is consistent between CSS
and SVG.
- A similar interface can be used for modifying either the Animation or
the markup thing that generated it, since, for example, both
AnimationTemplates and Animations include a Timing object. Furthermore,
the interface is the same for both CSS and SVG and hopefully much nicer
than using the CSSOM or SVG's limited API.
So, that's the background for them, but they may not be necessary for v1.
> D.1 Separate timing from animation.
> -----------------------------------
>
> While this is partly true in the proposal, there needs to be a bigger
> separation of timing from animation. In other words, it should be possible to
> have elements controlled by time, rather than just move/animate over time.
I looked at adding another primitive specifically for this--i.e. an
action that takes place at a given instant, as opposed to an effect that
varies over time.
However, in the interests of keeping the API simple I realised that this
can be easily achieved (and efficiently implemented) using a
zero-duration animation.
For example, see the section on calculating the iteration duration. By
setting sensible defaults (duration: 0, fillMode: forwards) it is
possible to make an element fade out and then be set to display: none (a
*very* common effect) by writing:
new SeqGroup(
[
new Animation(elem, { opacity: '0%' }, 1),
new Animation(elem, { display: 'none' })
]
);
Likewise a simple property at a given time might be achieved as:
// Display at time 3 seconds
elem.animate({ display: 'block' }, null, 3);
(This extension to the Element interface has yet to be added to the spec
but I expect we will have something like this.)
> For example, one could imagine a timed document that simply applied some CSS
> pseudo-class to elements when they were "active" (between their start and end
> times - not to be confused with the existing use of "active"). Then animations
> could be written in CSS, effectively giving a timing model to CSS.
The :time pseudo-class? [5] This is something that has informed our
design.[6]
In the current model this can be realised with an AnimationFunction
(possibly soon to become 'AnimationEffect') that sets the pseudo-class
when the time fraction is non-null (call it CSSSelectorEffect?). It's
simply up to the CSS integration to expose this through appropriate markup.
Of course, re-using Animation interfaces in such a way makes some of the
timing parameters such as the easing function meaningless. If such a
feature is exposed through CSS then I expect implementations will
optimize for the case of an Animation using a CSSSelectorEffect by not
sampling the effect unnecessarily within the active time span.
If you think this is problematic then I'm open to reconsidering adding
primitives especially for these cases. For now I thought it best to keep
the API simple.
> D.2 Media synchronisation.
> --------------------------
>
> The ability to synchronise any animation/timing to that of a media stream
> is essential. This is listed in the proposal but not clearly addressed.
Yes, it's very high on the todo list at the moment. There are notes
concerning this on the agenda for the next meeting.[7]
> D. CSS Transitions.
> ===================
>
> It's not clear how CSS Transitions fit into the proposal. One of the most
> common requests we get is from developers who want to know what transitions are
> running, or whether a transition did run (the transitionend event is not enough
> because it doesn't fire when nothing happened).
>
> Both animations and transitions are conceptually "Animations", and share almost
> the same implementation in WebKit. However, it's likely that from a developer
> perspective Transitions are different enough that they should be covered by a
> separate specification.
>
> In other words, we think transitions are out of scope for this work.
I think saying, "it's likely that from a developer perspective
Transitions are different enough that they should be covered by a
separate specification" is not sufficient justification for ruling them
out of scope.[8]
I think it would be better to attempt to try and write the spec
expressing transitions in terms of the same model as animations and then
consider if it makes sense or seems awkward.
As mentioned previously we hope it will be possible to write an
animation debugger to view *all* animations in the document regardless
of the markup used to generate them. If transitions were excluded, that
would be surprising. Returning to your first point, does that count as a
use case, requirement, goal, hope, dream or ambition?
Thanks again Dean.
Best regards,
Brian
[1] http://www.w3.org/Graphics/fx/wiki/Web_Animations/Use_cases
[2] http://parapara.mozlabs.jp/
[3] See https://etherpad.mozilla.org/ep/pad/view/MzLg1iUKv4/4sPNmceDjl,
point 6, "The chopping block". Specifically, I removed
TimingFuncCallback last week.
[4] https://github.com/shans/web-anim-js
[5] http://lists.w3.org/Archives/Public/www-style/2012Jul/0703.html
[6] http://lists.w3.org/Archives/Public/www-style/2012Aug/0148.html
[7] https://etherpad.mozilla.org/ep/pad/view/MzLg1iUKv4/4sPNmceDjl, point 3
[8] I've been working on some animation projects over the past year that
incorporate CSS Animations, CSS Transitions and SVG Animations and I
don't see transitions as belonging to a sufficiently different category.