Web Animations/Meetings/Meeting 9
< Web Animations | Meetings
Time, location: 5 Mar 16:30 PST / 6 Mar 11:30 AEDT / 6 Mar 09:30 JST, #webanimations
Agenda
- Accessibility—triggers
- Hardware acceleration
- Relationship to CSS transitions
Resolutions
- 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!