Web Animations/Meetings/Meeting 10

From Effects Task Force
< Web Animations‎ | Meetings
Revision as of 01:36, 9 March 2012 by Bbirtles (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Time, location: 8 Mar 16:00 PST / 9 Mar 11:00 AEDT / 9 Mar 09:00 JST, #webanimations


  1. API / Object primitives


  • Shane to investigate issues with getMatchedCSSRules


<birtles> ok, shall we get started?
<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_10
<birtles> agenda so far:
<birtles> 1) API / Object primitives
<birtles> 2) Synchronization discussion
<birtles> any changes?
<shans__> I did some experiments on requestAnimationFrame
<shans__> guess that goes under 2 actually
<cabanier> no changes from me
<birtles> yeah, did you want to change the order Shane?
<birtles> if not, http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Primitives
<shans__> nope, let's go with that order
<birtles> ok, so, where are we up to....
<birtles> to stack or not to stack?
<shans__> think so :)
<birtles> (I added a PhD thesis to the bottom of the page :( )
<shans__> I wanted to address your comment about whether all UAs build up styles as a stack
<shans__> does Mozilla not do this?
<birtles> I don't know
<shans__> because it's pretty hard to imagine how you'd elide the first .foo { } rule in your example
<birtles> it just felt like any implementation detail that I didn't want to expose
<birtles> s/any/an/
<cabanier> yes, it seems like it's needed
<shans__> you need to keep it around for the CSSOM, for the inspector (in WebKit, Firefox has an analogue too now, right?)
<cabanier> the ordering of your css creates the stack
<birtles> from my limited work on the style system in Gecko I haven't encountered something that maps to the stack, but I really don't know
<shans__> and furthermore, if you did work out how to elide it, it would just mean that the length of the stack would be different, not that there wouldn't be a stack
<birtles> but the lengths have to be the same between implementations
<shans__> Rik: right, it's implicit in the standard
<shans__> why?
<birtles> for interop
<shans__> the lengths of the WebAnimations stacks, you mean?
<birtles> yeah
<shans__> sorry, thought you were talking about the existing CSS stacks
<shans__> hmm
<shans__> not sure. It'd be nice, but not essential imho
<birtles> what would be nice?
<cabanier> what do you mean with the lenght of the animation stack
<shans__> the same lengths
<birtles> for web animation stacks?
<shans__> I think Brian means that if we adopt stacks of Animators, then he'd like the lengths of the stacks to be the same for the same CSS across UAs
<cabanier> seems like they should be
<cabanier> I don't see why it would be different
<birtles> yes, that's critical
<cabanier> the important thing is that they resolve to the same animation
<birtles> I'm still uncomfortable with exposing this
<birtles> what's the requirement here
<shans__> Brian, why is it critical? Without stacks there's absolutely no way to go from an element's animator to the styles that generated that animator
<cabanier> yes, you need to be able to combine rules
<shans__> with stacks, there are. Are you saying that feature is not worth including if we can't ensure all UAs expose styles that have no contribution?
<cabanier> and combine half finished rules
<birtles> it's essential for interop that the same style sheet gives you the same stack in different UAs
<cabanier> it's like a css om for css animations
<birtles> right, so in my essay I said, "It seems to me the main requirement that the stack API addressses, is to provide a typed API to style rules with animation properties for the purposes of (a) modification, and (b) extension."
<birtles> is that correct?
<shans__> yes. In my mind (b) is critical. It allows you to update CSS-only animations with features in our API that haven't been exposed to CSS yet.
<cabanier> yes
<birtles> ok, I'm less concerned about (b) but happily consider myself out-voted on that
<shans__> I think it's critical (1) for developers to be able to do this easily, and (2) for CSSWG members to be able to do this to prototype Web Animation features in CSS
<shans__> it's functionality which the API as it stands already provides to SVG. I don't want CSS to be a second class citizen.
<shans__> I think (a) is important as well, because  it provides a much nicer API for developers to play with these animations than the CSSOM does / probably ever will.
<birtles> ok, fair enough
<birtles> consider me sold
<birtles> ok, so what do you think of the concern that you really need to know what selector you're dealing with in order to make sensible changes to Animators?
<cabanier> :-)
<shans__> hmm
<birtles> (I'm not agreeing to the stacked API *yet*, just the requirements it addresses)
<cabanier> why do you need to know?
<shans__> heh :)
<shans__> that is a valid concern. It strikes me the same is true of knowing what <animation> element you're dealing with wrt to an SVG-derived Animator
<birtles> Rik, see, for example, use case 4
<shans__> so I propose a nullable field for CssStyleRule, and a nullable field for SvgElement, in the Animator interface
<birtles> ok, I hadn't thought of that--it's interesting but feels a little clumsy?
<birtles> my alternative proposal for addressing the requirements is something along the lines of window.getAnimatedStyle(".foo")
<birtles> the reasons I prefer this approach is:
<birtles> a) don't expose implementation details (stacking)
<birtles> b) you know what selector you're dealing with
<birtles> c) it's a separate style interface for dealing with style
<shans__> ok, so that could work for me too. window.getAnimatedStyle returns an AnimatorList?
<birtles> yeah, probably, I haven't thought through all the semantics
<birtles> but yeah, if you had two rules with the selector (".foo") it would return both
<shans__> I'd still like to be able to traverse from the Animator back to its components
<birtles> why?
<shans__> but that can always be another API call on the Animator
<shans__> it's useful for debugging, which is actually really important
<shans__> we sometimes forget that the Web Platform *is also* the debugging environment for web devs :)
<birtles> I'm with you on that
<shans__> cool
<birtles> but it sounds like something you want for any kind of style stuff?
<shans__> so it's important to be able to trace the contributors to an Animator, even if you don't necessarily want to do that in prod
<shans__> absolutely
<shans__> the inspector lets you do it
<birtles> right, same in firefox
<birtles> is it something we specifically need to solve for animations though
<shans__> but because we can grab an Animator and retarget it at other Animations, I don't expect the inspector would necessarily be able to keep up with all the cross-dependencies
<birtles> oh, I'm starting to get a picture of what you mean
<birtles> can you give a concrete use case, either now, or later on the wiki?
<shans__> yep.
<shans__> here's a sketch of one.
<shans__> I have an element that's animating. I grab the element's Animator and create a new Animation for another element.
<birtles> hang on...
<shans__> Later, that element does something I don't expect. I want to know exactly what's happening. In order to do so, I need to grab its Animator and trace back through all contributions.
<shans__> sorry
<birtles> I want to clarify a few things in that first sentence
<shans__> yep
<birtles> an element that's animating = an element being animated? or <animate>, i.e. animating something else?
<shans__> an element that's being animated
<shans__> by .. something
<shans__> (one of: script, CSS, SVG, via Web Animations primitives)
<birtles> so it's window.getAnimatedStyle(elem) or something of that sort which returns a list of Animation objects
<cabanier> you mean script via animation primitives
<birtles> and you take one of those animation objects and get its Animator?
<shans__> yep
<shans__> ah no
<shans__> sorry
<birtles> Rik, yes, that's right
<shans__> elem.getAnimations()
<shans__> and you take one of those animation objects and get its Animator.
<birtles> ok, yes, getAnimatedStyle is a bit of a misnomer
<cabanier> ah yes, you can have more than one animation going per element, and each can be a stack
<shans__> yep
<shans__> hmm
<shans__> interesting, there's another use case.
<shans__> "I want the animator that is animating *this* element (out of possibly many), but which is derived from *this* CSS rule"
<cabanier> yep
<cabanier> or this 'stack' of css rules
<shans__> yeah
<shans__> ok, I can definitely flesh out those 2 as use cases
<shans__> I think that applies to SVG too, right?
<birtles> what's that?
<shans__> "I want the animator that is animating *this* element but which is derived from *this* SVG rule"
<shans__> although that's a lot simpler because each SVG <animate> element only generates one Animator, whereas each CSS StyleRule contributes to multiple.
<birtles> yeah, SVG as it currently stands is simple
<birtles> but we want to change that
<birtles> e.g. <animate select=".foo" ... />
<shans__> ah yep. In which case the same use case definitely stands
<birtles> but still, you only need one Animator object right?
<birtles> I don't quite get the use case
<shans__> no, because what if there's multiple <animate select="…"> that all apply to the same element?
<birtles> yeah, but each <animate> still corresponds to one Animator right?
<shans__> e.g. <animate select=".foo" .../><animate select=".bar .foo"/><div class="bar"><div class="foo"></div></div>
<cabanier> I believe you are right Brian
<shans__> yes, I think so too
<birtles> oh ok, I think I misunderstood the use csae
<shans__> hmm, maybe this isn't an issue
<birtles> yeah, maybe it's ok
<shans__> because the semantics of that is that the animations are additive, rather than that the more specific selector overrides properties of the less specific one
<birtles> yeah, that's right
<shans__> cool :)
<birtles> ok, well, I think we've moved a little further on this issue
<shans__> yeah, definitely.
<cabanier> so, for my issue of knowing what selector you're dealing with, is it important because you don't want to change other animated item?
<birtles> we agree on the requirement for a typed API to access style rules with animation properties
<shans__> Rik: yep
<cabanier> s/knowing/needing to know
<birtles> knowing what selector you're dealing with is important so you know the scope of the changes you're making
<cabanier> ah, OK
<birtles> otherwise you're just poking in the dark
<cabanier> got it
<shans__> I really do think recording the source of each Animator will be useful in general, because any given element might have animation contributions from CSS, SVG *and* script
<birtles> I am seeing more of the utility here
<shans__> and some of these contributions might even be CSS or SVG *via* script (!)
<cabanier> and if you call it with no string, you get a private copy (so you know you don't change anything else)?
<shans__> e.g. elem.getAnimations()[0].getAnimator().animateElements(…);
<cabanier> yes, you will have to flag the script ones as different somehow
<shans__> yeah
<cabanier> I can see this working...
<shans__> couple of possibilities: (1) script-based Animators are identifiable because they have null StyleRule and SvgElement fields, and no ContributingAnimators (however we expose that); or (2) when created, script-based Animators can be given a name which can be retrieved later.
<birtles> or you just have subclasses of Animators
<cabanier> Why not do 1) with 2) optional. I can see value in both
<birtles> for example, I imagine an SVGAnimationElement could be a subclass of Animator
<birtles> likewise you could have CSSAnimator
<shans__> yep, so you look at the type. That works nicely too
<birtles> ok, I think we've come a long way, but, sorry to be so stubborn about this, I'm still concerned about the stack per se
<birtles> I wonder if there are other ways to provide similar features
<shans__> that's OK. One alternative that's presented itself here is to expose the "stack" via an API call
<shans__> that means it can be generated on demand rather than a permanent part of the object
<shans__> which might allay some of your concerns?
<birtles> but even then, I'm concerned about getting good interop there, it feels like it could be a barrier to implementation
<cabanier> Brian, why do you think that there is a problem with interop?
<cabanier> are there more implied rules in firefox than webkit?
<shans__> ok, why don't you take an action to talk to David Baron about how Mozilla deals with specificity in CSS?
<shans__> and we can see if there is actually going to be an issue
<shans__> btw, the same CSS sheet could potentially produce different sized stacks in different browsers simple because of user style sheets
<birtles> that's good, but even if Gecko is identical to Webkit, what about Presto and Trident and Abbra etc.?
<shans__> so it's an issue you need to deal with regardless of differences in UAs
<birtles> well then, that's a bigger problem isn't it?
<birtles> it just feels like we're exposing implementation details which constraints what implementations can do in the future
<shans__> not really. The point is that we think knowing the provenance of an Animator is desirable
<shans__> it's not an implementation detail though.
<shans__> it's a direct consequence of the CSS specification
<birtles> I wonder if it's desirable enough to warrant the burden on all implementations
<shans__> in particular the parts that discuss specificity and text order
<birtles> if we end up with situation where one user agent doesn't produce an Animator for an elided rule, then the API becomes useless?
<shans__> well I don't see there being a burden. Basically there's no way to construct the Animator without (a) having access to all of the style rules that could contribute, and (b) ordering them according the CSS rules for specificity
<shans__> I don't think so at all
<shans__> the purpose of having the information is not destroyed by non-contributing Animators being absent
<shans__> because it's there so you can find the contributing Animators
<birtles> but then content can't rely on Animators[4] being what they expect
<shans__> but I don't think that's what the feature's there for
<shans__> it's there for debugging, mainly
<birtles> ok, then for debugging, is there another path
<shans__> (if they want Animators[4], they can use the approach you suggested, of getAnimatedStyle(".foo")
<cabanier> an animator could just have the animation duration, which is put on the stack of all animators. change the one animator and all animations will change
<shans__> yeah that's a point too.
<shans__> it's a really bad idea to elide rules from the list in any implementation, because CSSOM updates could become *very* expensive
<shans__> sometimes specification really does dictate implementation, to an extent :)
<cabanier> elide?
<shans__> remove
<cabanier> ah. thanks
<cabanier>  Brian, are you going to talk to David about this? 
<birtles> yeah, but like I said, it's not just about Gecko
<cabanier> I think even if the stack are differents, it's OK
<birtles> I'm really keen to hear other ideas about how to address the debugging scenario
<shans__> let's see if we can state the requirement cleanly
<cabanier> yes, debugging is important. A clear view with the inspector, also means that it's easy to use in JS
<shans__> first question: we're happy with a requirement for CSS Rules to generate Animators, right? This is the "typed interface"
<birtles> I'm pretty sure, if we expose a stack web authors will start to rely on it, write content against it, and then any UA that does things differently will be considered buggy and "the Web will define the behaviour for us"
<cabanier> I am
<birtles> yeah, I'm ok with that
<cabanier> (that was my answer to Shane, not Brian)
<shans__> So could our requirement be: "It must be possible to derive the list of Animators that contribute to the final values of a given Animator"?
<cabanier> I can see that Brian...
<shans__> s/list/set maybe?
<cabanier> Shane, yes
<shans__> Brian: is that OK?
<birtles> I'm not sure if that amount of details is necessary
<cabanier> I guess that list should be the same on every implementation...
<shans__> what would you say then, Brian?
<birtles> I have two thoughts here...
<birtles> 1) for fonts and so on, there's currently no API I'm aware of that will let you know which rules produced all the different properties
<birtles> e.g. you might have font-size from one rule and font-weight from another
<birtles> who knows, maybe there should be an API for that?
<shans__> ok, but there's no way to take a font and apply it to a different dive
<shans__> er
<shans__> div
<birtles> exactly, that's the next point
<shans__> so you can always jump into the inspector
<birtles> 2) animations are different because you can apply them to arbitrary targets
<shans__> oh
<shans__> also
<shans__> every contribution to the font must come from CSS
<shans__> there's no way to change the values in script (except via the DOM or OM, which ends up back in CSS and in the inspector)
<birtles> well, you can have SVG presentational attributes
<birtles> font-size="2em"
<shans__> as in style=".."?
<shans__> see point about DOM ;-)
<birtles> it doesn't change where this is going
<birtles> I wonder if it's enough to be able to just get the animations targetting an element...
<birtles> you get the Animators for each one
<birtles> you can use the type to work out if it's from CSS or not
<shans__> ok
<birtles> for CSS ones you get the fully resolved set of properties
<shans__> but that doesn't give you enough information
<birtles> right
<shans__> you can't use it to tweak CSS rules, for example
<cabanier> yes, you need to know where they came frm
<birtles> but then I wonder if there's some way you can either get the element that Animator came from or the style rule
<birtles> and then you can look up the element or style rule in the inspector to get the cascade
<birtles> i.e. don't bother having the whole stack in the API
<birtles> leave that as something for the inspector to do for you
<birtles> just give the leaf for it to look up
<cabanier> It would be hard to figure that out where the rules came from
<shans__> you can't currently get the cascade in a standard way.
<shans__> webkit has a rule
<shans__> an API call rather
<shans__> but I don't think it's being standardized
<birtles> yeah, but I think the use case here was "the animation does something I don't expect"
<birtles> so I'm imagining an interactive debugging session here
<birtles> i.e. it's not fully programmatic (although some UAs might allow you to do that)
<cabanier> I believe this is useful for scripting too
<cabanier> not just debugging
<birtles> I just wonder if it's useful enough to warrant the complexity
<shans__> Yes!
<shans__> because the point is, that complexity is going to bite the developers
<shans__> and it's only a feature like this which will make it manageable
<birtles> I mean, if you get a font that doesn't match your expectations, you can't debug that programmatically--you need to do it interactively
<birtles> I'm saying, we add enough support to get developers to an equivalent position to the font case
<cabanier> I would say that's a flaw
<cabanier> in the API
<birtles> i.e. give you the leaf you need
<shans__> I think I can see what you want to do. The problem is that firebug and the inspector are completely beyond the reach of specification
<birtles> in which API?
<birtles> the CSSOM? or the Web animations API?
<birtles> I mean, if we agree the CSSOM should be able to give you a stack so you can debug fonts programmatically
<birtles> then that's great
<cabanier> yes
<shans__> actually, WebKit seems to have removed the CSSOM stack functionality
<birtles> let's get the Web animations to that point and then let the CSSOM take over
<shans__> so I'd say that's pretty much off the table
<birtles> why did they remove it?
<cabanier> overhead?
<shans__> this is a guess: possibly because Apple tried to standardize it and couldn't make a case to the CSSWG.
<cabanier> but why not leave it in with a prefix?
<cabanier> maybe it's in the changelist
<shans__> I don't know?
<shans__> yeah let me try to dig deeper. Want to give me an action?
<birtles> thanks
<birtles> I think that's probably important background to what we decide here
<birtles> I'd be much more comfortable with having a stack if it was something that you could use across all of CSS and we just fed into that API
<shans__> btw
<shans__> if there's a way to do this like you suggest (Animator -> origin source element -> CSS rule stack -> CSS Animators)
<shans__> I'm … ok … with that, but not happy
<shans__> the differences between ok and happy are:
<shans__> (1) this is roundabout (sure you can make it easier with a library, but why not just make it easier?)
<shans__> (2) we rely on the CSSWG to specify both the origin source element -> CSS rule stack *and* the CSS rule stack -> CSS Animators components
<shans__> which means in practice this may not be possible for years
<cabanier> o yes
<shans__> oh interesting
<birtles> we could kind of do the second part of (2) ourselves
<birtles> i.e. you get the stack, query the selector for the rule, and then use window.getAnimatedStyle(selector)
<shans__> origin source element -> CSS rule stack might actually now be specified, rather than removed. I might have been too pessimistic :)
<birtles> I'm concerned that in exposing the stack there are a lot of details (like elided rules, what order they go in) which are hard to get consistent across UAs--it's something which is not impossible but warrants a separate spec, particularly as it would have utility beyond animations
<birtles> in that case, I'm ok with it
<birtles> do you have a link?
<shans__> nope, it's not specified
<shans__> sorry
<shans__> not specified, and not prefixed
<shans__> bad WebKit :(
<shans__> there's a mozilla bug for implementing it in Firefox
<shans__> looks like there's broad support for the idea
<birtles> ooh, that is interesting
<birtles> do you have a bug id?
<shans__> https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cts=1331255752940&ved=0CCUQFjAA&url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D438278&ei=XFlZT87LO4LImQWcupS3Dw&usg=AFQjCNFD7kVV6PsVP_y_-bPwN6qzKCwB4g&sig2=DAKQQPeTZaUmCYZqhuR6NQ
<shans__> ouch
<shans__> 438278
<birtles> sounds like there are security issues
<birtles> "the latest comments have been suggestions to remove this feature from Webkit"
<birtles> webkit bug 35015
<cabanier> "I assume there's a security problem."
<shans__> hmm that bug is a security bug which means we can't see it
<cabanier> can you see it since you're on the inside?
<birtles> yeah, you can ask to be CC'ed on it
<birtles> I could ask Boris
<shans__> let me try that
<shans__> you can't ask to be cc'd?
<birtles> yeah, I mean "I could ask Boris to be CC'ed"
<birtles> but I don't have a webkit login and Boris is not online atm
<shans__> btw that's an *old* bug
<birtles> so you might be able to get access sooner
<shans__> 35016 is from feb 2010
<shans__> so we're talking about it being "a security risk" for 2 years with no action
<birtles> yeah, it would be good to know what the issues are
<shans__> yep
<birtles> I think I'd be more comfortable with feeding into such an API
<birtles> but not defining it ourselves
<birtles> alright, let's wrap this up for now
<birtles> I think we have a few actions
<shans__> ok, so to summarize what we know: getMatchedCSSRules is not standardized. WebKit has an implementation with an unknown (but long-standing) security issue. Mozilla will implement if WebKit resolves the security issue.
<birtles> yes, I think that's right
<shans__> yeah I'd like to wrap up too
<shans__> I think we've made a lot of progress today :)
<birtles> agreed, thanks everyone
<shans__> thanks Brian :)
<shans__> next meeting?
<cabanier> yes.
<cabanier> monday/tuesday next week?
<shans__> I can do that
<birtles> first, who is going to take the action to investigate the getMatchedCSSRules API?
<shans__> I will
<cabanier> I believe there is a time change coming
<shans__> sounds like I'll have the best chance of getting on that bug
<birtles> yeah... it gets harder
<birtles> thanks Shane
<birtles> I'm afraid the first half of next week is not much for me
<shans__> ok, how about wed/thu then?
<cabanier> I will be out the second half of next week and the first half of the following week
<birtles> that's better
<shans__> heh
<birtles> oh :)
<shans__> hmm
<shans__> tue/wed?
<shans__> or is that the first half for you, Brian?
<birtles> Rik, does the second half of next week include Wed?
<cabanier> let me check
<cabanier> wednesday works
<birtles> I can do tues/wed if we move it forward 1 hour (but it's not something I want to do every week)
<cabanier> so wed/thurs?
<birtles> is the same time ok Rik, it will be 17:00 for you I think
<shans__> let's do wed/thu then, if wednesday works for Rick. If we move tue/wed forward an hour I don't get a lunch break :)
<cabanier> I can do 17:00
<birtles> ok, same time (for Shane and I), but 17:00 for Rik
<birtles> wed/thurs
<shans__> wed/thu
<shans__> great
<cabanier> I thought food was going on 24/7 at google :-0
<shans__> haha
<birtles> :)
<shans__> not the good stuff
<cabanier> ah
<shans__> righto, talk to you both next week
<birtles> fair enough... we should let you go!
<birtles> thanks Shane! thanks Rik!
<cabanier> ok. talk to you guys then