Web Animations/Meetings/Meeting 9

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

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

Time, location: 5 Mar 16:30 PST / 6 Mar 11:30 AEDT / 6 Mar 09:30 JST, #webanimations

Agenda

  1. Accessibility—triggers
  2. Hardware acceleration
  3. Relationship to CSS transitions

Resolutions

  1. We will continue the discussion about hardware acceleration when Alex is with us in Tokyo

Log

<shans_> hey guys
<birtles> hey!
<birtles> cabanier[A], you ready to meet?
<cabanier[A]> yes
<birtles> great
<birtles> ok, http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_9
<cabanier[A]> why am I with an [a]?
<birtles> you got marked "away"
<birtles> apparently
<shans_> Rik - auto-away
<birtles> I don't support it auto-restores you though
<shans_> heh
<birtles> s/support/suppose/
<birtles> I think you just need to change your nick
<birtles> agenda is:
<birtles> 1) API / Object primitives
<birtles> 2) Hardware acceleration
<birtles> 3) Synchronization discussion
<cabanier> better :-)
<shans_> I'd like to talk about a11y again today too
<birtles> sure
<birtles> shall we make that (1) or (2)?
<shans_> I found out about triggers
<shans_> um, maybe (1)?
<birtles> ok, let's make it (1)
<cabanier> ok
<shans_> I'll try to be brief
<birtles> I added "h/w acceleration" but it should be pretty brief
<birtles> I just wanted to bring it up
<birtles> anything else to add to the agenda?
<shans_> maybe we should keep that a (2) then
<shans_> and have API/Object as (3)
<birtles> 1) a11y
<birtles> 2) Hardware acceleration
<birtles> 3) API / Object primitives
<birtles> 4) Synchronization discussion
<birtles> any other changes?
<birtles> if not, (1) a11y
<shans_> OK so with triggers, the news isn't good. I thought I'd just described what I'd learned, and maybe we can think about it and have a longer discussion later.
<birtles> please tell us what you found Shane
<birtles> ok
<shans_> s/described/describe
<shans_> at the moment there's 2 ways to trigger animations (etc.) in HTML / CSS / JS
<shans_> through CSS for really simple things (hover, etc.)
<shans_> and through JavaScript
<birtles> and, I guess, document load
<shans_> that's through JS though, right?
<shans_> document.onload?
<birtles> no, just the way CSS animations are defined
<shans_> anyway, a11y pretty much depends on any complex behaviour being triggered through JS
<birtles> that they run at document load if they are resolved then
<shans_> ah right yep
<shans_> ok, that's "through CSS"
<shans_> but yeah
<shans_> so take for example an animation that slides down a menu when you e.g. mouse-over
<shans_> for that to be accessible, you need to be able to mark the menu div as the active child of the triggering element
<shans_> and that in general either needs javascript, or a pretty massive amount of declarative primitives that we haven't defined anywhere else in web standards
<shans_> (you need to do a bunch more as well, not just that)
<cabanier> hmm
<cabanier> style vs content...
<shans_> style vs. content is basically completely broken wrt animations though, right?
<cabanier> yes.
<shans_> and this is the problem
<cabanier> I see.
<cabanier> hmmm
<shans_> so
<shans_> we have 2 choices, and *maybe* a third
<shans_> (1) trigger only through js, and we don't need to do anything special for a11y because the js primitives are already available
<shans_> (2) include the current set of SVG-style triggers and make sure we include an a11y expert *early* to tell us what extra declarative primitives we need (but this will be a looot of work)
<birtles> just to clarify, with (1) "js primitives" are what in this case?
<shans_> a11y APIs
<shans_> I can't actually point you to a doc about those, although I could ask Silvia if you want?
<birtles> i.e. the script is responsible for making calls to a11y APIs
<shans_> yeah
<birtles> ok
<birtles> maybe this is opening a big can of worms, but I think with the style vs content thing...
<shans_> I think how it works is: things need aria roles to be acessible
<shans_> but often they don't act in that role until triggered
<birtles> I'd like a situation where you use CSS animations for stylistic flare etc.
<shans_> so you need to associate the role with them
<shans_> (once they're activated)
<birtles> ok
<cabanier> it seems that it should be attached to the content
<birtles> but you use the element syntax for cases where the animation is the content... although I realise the line there is not always that clear
<birtles> in which case it makes sense to leave triggers out of CSS
<birtles> and just in the element syntax
<shans_> well no, the other way round
<shans_> triggers + animation as content are exactly the problem
<cabanier> Adobe has some rules on making Flash animations accessible: http://www.adobe.com/accessibility/products/flash/best_practices.html/http://www.adobe.com/accessibility/products/flash/text.html
<birtles> I think you could infer relationships between triggers and stuff with the current features of SVG
<cabanier> not sure if it helps
<shans_> I really don't think you can, but maybe I can provide some motivating examples
<birtles> yeah, which is why I think "triggers + animation as content" are best left to the element syntax
<birtles> well, maybe it's not easy, but it might be fixable
<shans_> wait, I don't understand
<shans_> the problem is declarative triggers when animation is the content
<shans_> because you can't do any of the a11y stuff
<birtles> I mean <animate begin="rect.click" ... /> seems like it should be parseable into some sort of relationship
<shans_> that's not the issue though
<shans_> the issue is that the *result* of the animation is a menu
<birtles> I still don't get what's missing there---the result is declarative as well
<shans_> alright, here's a somewhat contrived example
<shans_> we have a bunch of six icons around the periphery of the screen
<shans_> they're non-reactive
<shans_> when you click on something in the middle of the screen, the icons shift into place underneath the thing you clicked - and are now a reactive menu
<shans_> for a menu to be accessible, it needs to have aria roles associated with it
<shans_> I think with each child, but I'm not sure
<shans_> but if the aria roles are associated before the animation occurs, then the accessibility tool thinks there's a menu available to be used - when at that stage there isn't
<shans_> so you really need to do some processing *at activation time* for it all to work consistently
<birtles> so "role" needs to be animatable as well?
<cabanier> or able to transition
<birtles> <set attributeName="role" to="menu"> ?
<shans_> yeah but that might not be enough
<shans_> I'm not an expert in accessibility :)
<birtles> yeah, ok
<birtles> still, I'm not sure what we need to decide here
<birtles> I think the declarative triggers address *some* use cases
<birtles> e.g. alternative input devices
<shans_> me neither. I just wanted to flag that there's a big issue with declarative triggers and a11y
<birtles> whilst perhaps not supporting all uses cases in terms of ARIA roles
<shans_> which we will need to work through at some point, if we believe in the use-case of animation-as-content (which I do)
<cabanier> Maybe we should come up with a proposal and then ask experts
<birtles> yeah, but pehaps this is a secondary issue?
<cabanier> otherwise it seems like we might overthink it...
<shans_> that sounds like it could work. We should also look at the use-cases that support declarative triggers
<shans_> maybe there's some simple way to support them non-declaratively
<birtles> yeah, I'm not so keen on cramming all the sort of triggers in SVG into CSS
<shans_> btw
<shans_> the maybe 3rd approach that I was thinking of is that we can provide for some kind of co-trigger that might make it convenient for adding a11y properties to a declarative animation
<shans_> but I don't really know exactly what that would look like or how it would work
<birtles> ok, fair enough
<birtles> I think there may be a middle ground of having some API for this but not exposing it declaratively to CSS
<shans_> wait, no
<shans_> the problem is SVG + triggers
<shans_> I know there are already triggers in SVG
<shans_> but they are the problem, at least according to Silvia
<birtles> what's the issue?
<shans_> the issue is that if you use declarative triggers in a content animation, especially if that animation is part of the UI, then you can't make it accessible
<birtles> please explain
<shans_> I thought I had, with the menu example?
<birtles> I couldn't see any issue there so long as "role" as animatable
<birtles> but maybe we should just leave this topic
<shans_> well, role isn't animatable right now, right?
<birtles> I don't think it's going to impact the core of the API
<birtles> so we can come back to it later right?
<shans_> I think so
<birtles> ok, thanks for looking into that
<birtles> I think we have a bit better idea of the sort of issues involved
<birtles> so (2), h/w acceleration
<birtles> I'm just bringing it up because Alex mentioned it on one of the mailing lists
<cabanier> is HW acceleration a concern?
<cabanier> what mailing list?
<birtles> yeah, just searching
<birtles> public-svg-wg
<birtles> http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0137.html
<birtles> "Right now the advantage of CSS animation is that it's easy to map to a H/W
<birtles> accelerated animation engine whilst I don't believe that's the case for
<birtles> SMIL."
<shans_> right
<shans_> yeah I remember that mail now
<birtles> anyway, I'm not sure what the parameters are for mapping for h/w
<cabanier> yes, I don't know what he means by that
<birtles> but if we had an idea of the lowest common denominator of h/w animation features
<shans_> I think I do
<birtles> then we can try to design our API to map easily to that
<cabanier> the rules of css are not applied by hardware
<shans_> I think what Alex was talking about is just that once a css animation or transition is generated (by software)
<shans_> it can be set up on a graphics card and just .. run
<cabanier> that's not really true
<shans_> the only events that can change the animation are explicit user actions
<cabanier> css animations can be nested
<shans_> they can?
<cabanier> yes
<shans_> do you have an example?
<cabanier> take the dog example
<cabanier> that I provided as a demo
<cabanier> there's an animation that goes from right to left
<cabanier> and it contains several animations that move the dog's head
<birtles> notepad
<cabanier> I can create some other ones that show it more clearly
<birtles> (oops, wrong window :)
<birtles> but you can decompose those animations right?
<birtles> into components that can be offloaded to the GPU?
<shans_> ok, but that's not a problem for hardware acceleration, the problem would be more like if you could trigger other css animations to start based on the position of the outer animation
<cabanier> yes
<cabanier> the animation itself is still done by the cpu. The GPU is just moving textures around
<cabanier> you can do this in script too and still use the GPU
<shans_> with WebGL?
<cabanier> no, straight HTML
<cabanier> translate-z:0 will do it
<shans_> ah, you mean it's just that the layers are transformed on the GPU
<cabanier> yes
<shans_> but other aspects of the animation (background color, etc.) aren't
<shans_> I'm not sure of the extent to which that is true in WebKit
<cabanier> I think background is uploaded to the gpu too
<cabanier> I'm not sure if webkit does it, but chrome and safari do
<shans_> (then webkit does :))
<cabanier> explorer 10 does it all the time
<cabanier> so their demos run fast in ie10 and slow in webkit
<shans_> in webkit
<shans_> opacity, transform, filter are
<shans_> and I think that's it
<birtles> I guess the main factor that prevents SVG animations from being accelerated is that it supports addition right?
<cabanier> no, i don't think it matters
<shans_> that's definitely one factor, although at least some sorts of addition can be supported on the card
<birtles> I mean, it's not that SVG animations aren't acceleratable at all...
<shans_> but I think the main issue is the syncbase stuff
<birtles> it's just that no one bothers
<cabanier> the coordinates are calculated on the CPU
<cabanier> shane, that is correct
<birtles> what's wrong with syncbase?
<shans_> setting up animation contexts on the GPU is expensive
<cabanier> I bet if the animated content had a translate-z, it would go on the gpu and your SMIL would be HW accelerated
<shans_> syncbase means that there's a range of situations where GPU would be slower than CPU-only
<shans_> but the cutoff is system dependent
<cabanier> I think this is out-of-scope for us...
<birtles> yeah
<birtles> I don't quite understand the specifics here
<shans_> well I slightly disagree, coming back to Brian's initial point
<birtles> I'm just trying to get a feel for the parameters
<birtles> so we don't define an API that's difficult to accelerate
<shans_> yeah, that point
<shans_> I think we should try to do that, or at least try to define an API where the decision to accelerate or not is simple
<birtles> should we wait until Alex is with us?
<shans_> yeah, I think we should
<birtles> ok, well I'll add that to the agenda for Tokyo then
<cabanier> there is a proposal to add a keyword that signals the browser to HW accelerate an animation
<cabanier> Ok
<cabanier> alex will be there too.
<birtles> yeah, I noticed Android has that: http://developer.android.com/guide/topics/graphics/hardware-accel.html
<shans_> yep
<birtles> ok, well, let's leave that topic for now then
<birtles> which brings us to (3) the API
<shans_> oh hey, did you guys get my email about the CSS Transitions & Animations demo?
<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Primitives
<shans_> (not on the agenda, I know, just wanted to make sure you'd gotten it)
<birtles> yeah, sorry, I haven't looked at it
<birtles> just a sec
<cabanier> shane, yes. I looked at it
<birtles> (I think I'm being bitten by vendor prefixes :( )
<cabanier> it explain the need for the keywords really well
<shans_> hmm, yeah I haven't tested on Firefox sorry
<shans_> I should do that
<birtles> looks good
<birtles> I'll look at it properly later
<birtles> unless there was something you wanted to bring up now?
<shans_> nope
<birtles> ok, while we're between topics
<birtles> Rik, I got your mail too
<birtles> "Are we integrating transitions too?"
<cabanier> ah yes
<birtles> I was of the understanding that, "Yes, we are"
<birtles> is that right?
<shans_> +1
<cabanier> I wasn't sure about it
<cabanier> they seemed different
<birtles> ok, I think we're trying to anyway
<cabanier> like, can you add a transition to an animation?
<cabanier> through the proposed API
<shans_> woah
<birtles> I think a transition is an Animation triggered by a CSS event???
<cabanier> because that's what it sounded like you said
<shans_> Rik, do you mean something like a transition over the animation-duration property?
<cabanier> exactly. We haven't discussed integrating transitions and that is an issue
<shans_> I think yes, you can, but we seem to be resolving that changing the value of a property doesn't impact in-flight animations, so you won't see the effect
<birtles> yeah, that's interesting, but something we haven't discussed yet
<cabanier> and is syncing important for them?
<shans_> actually I think the CSSWG has resolved that animation- and transition- properties are neither animatable nor tranitionable
<birtles> (SVG also says animation attributes are not animatable)
<cabanier> yeah, that would be hard to do :-)
<birtles> yep :)
<shans_> I think we can just preserve that behaviour, right? :)
<birtles> I hope so :)
<cabanier> yes please
<shans_> like, meta-animation is cool and all, but .. really?
<birtles> consensus! :)
<shans_> hooray!
<birtles> ok, let's move on while the mood is good :)
<birtles> how much time do you guys have?
<cabanier> well, it's almost 5:30...
<cabanier> I have to go soon.
<birtles> right... ah, API is (1) next time?
<shans_> yeah we'd better do that
<cabanier> yes
<shans_> hey maybe we could meet tomorrow?
<birtles> suits me
<cabanier> That won't work for me as I'm flying to San Francisco
<birtles> when are you next able to meet Rik?
<cabanier> the day after would likely work
<birtles> i.e. yours Wed, our Thurs?
<cabanier> yes
<shans_> that works for me too
<birtles> ok, 16:00/11:00/9:00?
<cabanier> sounds good
<birtles> i.e. the usual time
<shans_> yep
<birtles> alright, thanks guys!
<shans_> thanks brian :)
<cabanier> yes. See you on wednesday!
<birtles> see you then, have a safe flight!
<cabanier> thanks Brian!