- From: Lars Gunther <gunther@keryx.se>
- Date: Wed, 31 Mar 2010 15:55:50 +0200
- To: www-style list <www-style@w3.org>
2010-03-30 20:38, Robert O'Callahan skrev: > The expectation that disabling script disables animations doesn't hold > today: disabling script doesn't disable plugins, or animated images, or > <video>, or SVG animation. Nor should it disable CSS animations. That might be true. Since neither of us have done any usability studies on this we do not know, however. User expectations might change in the future. I still think its is plausible, though, that many users expect animation and scripted effects to be related. >We have > separate control in Gecko for disabling animated images and that could > be extended to disable CSS animations. > Which might solve one problem, agreed. However: It does not solve the other problems I have mentioned, which are about authoring. - Animations triggered by anything but hover and focus, eg. click, load, submit, XHR readystates, key events, etc. - Animations triggered by events on the non-animated elements, where CSS selectors are not enough to describe the relationship. - Setting animation properties through a script, e.g. changing the rules in a key frame, or creating rules programmatically. Neither does it address my concerns about having clean solutions. - Today we use imperative scripting to manipulate style attributes, to get animation effects. - Tomorrow we should use declarative scripting to achieve similar, but hardware accelerated, effects. There might be some pure CSS-animations on the web of tomorrow, but there will also be a lot of combined CSS-animation/DOM-scripting, with the current proposal. So can someone please answer this question: Why should setting and deleting classes on an element be the only way to do this combination? Why do you like to impose that limitation on the technology? -- Lars Gunther http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Received on Wednesday, 31 March 2010 13:56:23 UTC