Animation
rocal...@gmail.com
Currently there are several animation-related standards or proposed
standards:
-- SMIL Animation (W3C)
-- SMIL 1/2 (W3C)
-- CSS transitions (Apple)
-- CSS animations (Apple)
I think we reached a tentative consensus:
1) "Animated UI effects" and "Movie-like animations" are somewhat
different sets of use cases.
2) CSS transitions seems like a good solution for "animated UI
effects", assuming a satisfactory answer to the question of what
happens when, during a transition from A to B, the CSS property is set
to a new value C. We should press on with implementation.
3) SMIL is overcomplex, very difficult to understand in general and
even the Animation subset contains some unnecessary features (e.g.,
'event', 'wallclock' and 'accessKey' animation timing in SVG
Animation).
4) CSS animations wouldn't let us animate SVG because a lot of the
important SVG properties are not controllable via CSS.
5) Voluminous animation data (e.g. for a lengthy movie) should be in
markup rather than separated out into a CSS sheet.
6) Additive animation as supported by SMIL, but not the CSS animations
proposal, would be useful.
7) Overall, including other factors in favour of SMIL Animation (other
browser implementations, existing standard, etc), it seems best to
press on with implementing SMIL Animation.
8) During that process we should identify SMIL Animation features
superfluous to the needs of the Web, and try to develop a cross-
browser consensus to exclude those features.
Rob
Cameron McCormack
> 3) SMIL is overcomplex, very difficult to understand in general and
> even the Animation subset contains some unnecessary features (e.g.,
> 'event', 'wallclock' and 'accessKey' animation timing in SVG
> Animation).
SMIL is overly complex and difficult to understand.
I think eventbase and accessKey timing specifiers are useful, but I
agree wallclock is not.
> 7) Overall, including other factors in favour of SMIL Animation (other
> browser implementations, existing standard, etc), it seems best to
> press on with implementing SMIL Animation.
> 8) During that process we should identify SMIL Animation features
> superfluous to the needs of the Web, and try to develop a cross-
> browser consensus to exclude those features.
The SVG WG plans to take a detailed look at SMIL animation for SVG Core
2.0 (coming soon to an agenda near you?), so such a review would fit in
well at that point.
--
Cameron McCormack ≝ http://mcc.id.au/
Mike Beltzner
recommendation to:
- implement CSS transitions
- implement SMIL animation
Do we know if / have plans to make these features available to chrome
as well as content?
cheers,
mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
rocal...@gmail.com
> I think eventbase and accessKey timing specifiers are useful, but I
> agree wallclock is not.
What are the use cases for eventbase and accessKey? Web pages use DOM
event handlers and script to handle input events (except for the very
simplest forms), and I don't see any need to change that here.
Rob
rocal...@gmail.com
> Thanks for the overview, roc. By my read, this means there's a
> recommendation to:
>
> - implement CSS transitions
> - implement SMIL animation
>
> Do we know if / have plans to make these features available to chrome
> as well as content?
These would be usable by chrome as well as content.
Our assumption here is that CSS transitions would be sufficient for
chrome's animation needs. CSS transitions are very simple: you modify
a style property using script in the usual ways, and if a transition
has been specified on that element for that property, you get a smooth
transition instead of an instantaneous one, according to your desired
velocity profile. You should let us know if this is insufficient.
Rob
Neil Deakin
I am highly opposed to using the Apple proposed css transition feature
for XUL UI.
- it can only animate css properties, and not say, the scroll position
or dom attributes.
- a common usecase is to slide an element into view when it is inserted
or removed from a document. No CSS propertes change in this case.
- The Firefox notification bar for instance involves very complex (and
very stupid) stack and margin adjustment. It is conceptually easier for
an author to write 'slide the element in' than have to work out which
css properties need to be changed.
- the developer has little control over the behaviour of the animation.
It happens automatically when any change is made.
- the use of CSS generally implies that the animation would be
implemented by the theme author (and reimplemented by every theme)
- you cannot use preferences or other controls to disable or modify
specific animations, ie, you would get all or nothing.
- any extension features would be implemented as ugly '-moz-' like
properties.
- complex animations (with multiple steps for instance) aren't possible
with the transitions feature. They are more possible with the other
Apple animation spec, but it involves more complex css when I think that
information should really go in the XUL document (like your original
point 5).
For XUL I would prefer a markup based solution with a script api (and
such that the script api can be used without requiring markup as well).
Martijn
> I am highly opposed to using the Apple proposed css transition feature for
> XUL UI.
>
> - it can only animate css properties, and not say, the scroll position or
> dom attributes.
I wonder if it would be possible to have a css property to set the
scroll position of an element.
Regards,
Martijn
> - a common usecase is to slide an element into view when it is inserted or
> removed from a document. No CSS propertes change in this case.
> - The Firefox notification bar for instance involves very complex (and very
> stupid) stack and margin adjustment. It is conceptually easier for an author
> to write 'slide the element in' than have to work out which css properties
> need to be changed.
> - the developer has little control over the behaviour of the animation. It
> happens automatically when any change is made.
> - the use of CSS generally implies that the animation would be implemented
> by the theme author (and reimplemented by every theme)
> - you cannot use preferences or other controls to disable or modify specific
> animations, ie, you would get all or nothing.
> - any extension features would be implemented as ugly '-moz-' like
> properties.
> - complex animations (with multiple steps for instance) aren't possible with
> the transitions feature. They are more possible with the other Apple
> animation spec, but it involves more complex css when I think that
> information should really go in the XUL document (like your original point
> 5).
>
> For XUL I would prefer a markup based solution with a script api (and such
> that the script api can be used without requiring markup as well).
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Cameron McCormack
rob...@ocallahan.org wrote:
> What are the use cases for eventbase and accessKey? Web pages use DOM
> event handlers and script to handle input events (except for the very
> simplest forms), and I don't see any need to change that here.
Of course you can do everything with script-triggered animations that
you can with eventbase and accessKey ones, but I think it's somewhat
clearer to use them instead of having to write explicit event handlers.
For example:
<g id="MyWindow">
...
<image id="b" xlink:href="closeButton.png" width="20" height="20"/>
<animate attributeName="opacity" to="0" dur="1s" begin="b.click"/>
</g>
instead of:
<g id="MyWindow">
...
<image xlink:href="closeButton.png" width="20" height="20"
onclick="document.getElementById('a').beginElement()"/>
<animate id="a" attributeName="opacity" to="0" dur="1s"
begin="indefinite"/>
</g>
rocal...@gmail.com
> I am highly opposed to using the Apple proposed css transition feature
> for XUL UI.
>
> - it can only animate css properties, and not say, the scroll position
> or dom attributes.
For scrolling, we should have a dedicated scrolling API with a smooth
scrolling option, IMHO ... we already have that internally in Gecko,
we just need to expose it.
SMIL will be available for DOM attributes, but really it would be
better if we didn't rely so much on presentational attributes in XUL.
Which particular attributes are you concerned about?
> - a common usecase is to slide an element into view when it is inserted
> or removed from a document. No CSS propertes change in this case.
You could just set "height:0" before you insert the element and then
set "height:auto" to have it slide into view (for example).
> - The Firefox notification bar for instance involves very complex (and
> very stupid) stack and margin adjustment. It is conceptually easier for
> an author to write 'slide the element in' than have to work out which
> css properties need to be changed.
I'm not sure how to address that. Part of the problem there is the XUL
box model. And animation adds new degrees of freedom, so you won't
just be able to write 'slide the element in', you'll have to specify
*how* it slides in. I'd like to hear exactly what API you propose to
handle this case.
> - the developer has little control over the behaviour of the animation.
> It happens automatically when any change is made.
That's true, but I don't think it will matter in practice.
> - the use of CSS generally implies that the animation would be
> implemented by the theme author (and reimplemented by every theme)
Don't we support style sheets that are independent of the theme? I
thought themes being able to control animations was actually a good
feature.
> - you cannot use preferences or other controls to disable or modify
> specific animations, ie, you would get all or nothing.
Systematic use of classes and class selectors would seem to address
that.
> - any extension features would be implemented as ugly '-moz-' like
> properties.
Yes, but useful extensions would probably be rolled back into the
spec.
> - complex animations (with multiple steps for instance) aren't possible
> with the transitions feature. They are more possible with the other
> Apple animation spec, but it involves more complex css when I think that
> information should really go in the XUL document (like your original
> point 5).
What are the use cases for these in the UI? I'd look to SMIL for this.
> For XUL I would prefer a markup based solution with a script api (and
> such that the script api can be used without requiring markup as well).
I really want to avoid creating a third, non-standard, chrome-only
animation API. That's bloaty, and it reduces the synergy between Web
and chrome development that has served us well, especially in the
extension world. (I really love the work you did to use HTML5 drag-
drop in chrome.)
There is actually one more animation API I think we should add --- an
'onbeforepaint' DOM event that fires before we paint, and
'window.beginAnimation()' and 'window.endAnimation()' methods that
start and stop continuous update of the window. This would let us do
intelligent frame rate control while giving JS animation libraries the
ability to update their animations optimally. We'll need that because
there will always be animation needs that exceed what we support
declaratively, plus it's good to make it easy to retrofit existing
animation code to work better.
Rob
Zack Weinberg
> On Nov 3, 11:58 pm, Neil Deakin <enndea...@sympatico.ca> wrote:
> > - a common usecase is to slide an element into view when it is
> > inserted or removed from a document. No CSS propertes change in
> > this case.
>
> You could just set "height:0" before you insert the element and then
> set "height:auto" to have it slide into view (for example).
If the element contained text, wouldn't that cause line break
recalculation on every incremental resize from the animation loop, and
wind up looking awful? That's why, in bug 461292, the scrollframes are
being slid outside the bounds of an overflow:hidden mask rather than
having their width scaled down to zero.
zw
Jonas Sicking
>> - a common usecase is to slide an element into view when it is inserted
>> or removed from a document. No CSS propertes change in this case.
>
> You could just set "height:0" before you insert the element and then
> set "height:auto" to have it slide into view (for example).
This is a very interesting use case though, and one that I think should
be better addressed than through above two-step process.
Similarly things like transitions where one thing should be displayed
and another hidden.
/ Jonas
rocal...@gmail.com
Changing heights doesn't cause line break changes. In general it
depends on the content; sometimes you'd need an extra container, yes.
Rob
rocal...@gmail.com
Maybe. But animation infrastructure that requires intermediate states
which are not describable with non-animated CSS would be painful to
specify and implement.
Rob
rocal...@gmail.com
> Of course you can do everything with script-triggered animations that
> you can with eventbase and accessKey ones, but I think it's somewhat
> clearer to use them instead of having to write explicit event handlers.
> For example:
>
> <g id="MyWindow">
> ...
> <image id="b" xlink:href="closeButton.png" width="20" height="20"/>
> <animate attributeName="opacity" to="0" dur="1s" begin="b.click"/>
> </g>
>
> instead of:
>
> <g id="MyWindow">
> ...
> <image xlink:href="closeButton.png" width="20" height="20"
> onclick="document.getElementById('a').beginElement()"/>
> <animate id="a" attributeName="opacity" to="0" dur="1s"
> begin="indefinite"/>
But in reality, this "close" operation is rarely going to be
implemented entirely by an animation. Closing the window will involve
other behaviours, like saving state or changing layouts or checking
for unsaved data. And if you're going to have a "close window" script
(which will probably be invokable in several ways, e.g. a close button
and a command key), it may as well trigger the animation. Then we
don't have to repeat the list of commands that can close a window.
Basically I think it's going to be quite rare that you have input that
should *only* trigger an animation and have no other effect. And if
that's the case, providing convenient syntax for triggering the
animation isn't very useful.
Rob
Neil Deakin
> SMIL will be available for DOM attributes, but really it would be
> better if we didn't rely so much on presentational attributes in XUL.
Wrong, XUL is a presentational language and all of the attributes are by
definition presentational (or behavioural).
>> - a common usecase is to slide an element into view when it is inserted
>> or removed from a document. No CSS propertes change in this case.
>
> You could just set "height:0" before you insert the element and then
> set "height:auto" to have it slide into view (for example).
That's the naive answer that someone who hadn't thought of it would
give. The notification bar animation doesn't change its height at any time.
> I'm not sure how to address that. Part of the problem there is the XUL
> box model. And animation adds new degrees of freedom, so you won't
> just be able to write 'slide the element in', you'll have to specify
> *how* it slides in. I'd like to hear exactly what API you propose to
> handle this case.
As someone who spent quite a bit of time trying to get the notification
bar to work, I would say that being able to write 'slide the bar in'
rather than spending a day trying to work it out by hand would be a
great benefit. This is quite likely why jQuery's api is 'slideDown'
rather than 'adjustTheCSSHeightFrom0ToAuto'.
>
>> - the developer has little control over the behaviour of the animation.
>> It happens automatically when any change is made.
>
> That's true, but I don't think it will matter in practice.
Usability depends very much on being precise.
For instance what would happen if two notification bars need to appear
at once? I haven't thought about that particular case here, but not
being able to control what happens is not an effective way to build UI.
> Yes, but useful extensions would probably be rolled back into the
> spec.
You mean eight years from now?
>> For XUL I would prefer a markup based solution with a script api (and
>> such that the script api can be used without requiring markup as well).
>
> I really want to avoid creating a third, non-standard, chrome-only
> animation API.
You're confused. We don't have any animation APIs at the moment. The
Apple feature isn't a standard either, if that's what you're referring to.
I'm not particularly interested in what web sites want. I'm interested
in animation needs for the UI (Firefox for example). If web
specifications do not meet the requirements of the UI, then we should
implement other APIs that do. By the way, since you seem to have already
determined what animation apis you think should be used for the UI,
could you post the requirements that you gathered from the UI and
firefox teams for animation? You did do that right?
Boris Zbarsky
>> SMIL will be available for DOM attributes, but really it would be
>> better if we didn't rely so much on presentational attributes in XUL.
>
> Wrong, XUL is a presentational language and all of the attributes are by
> definition presentational (or behavioural).
I see no contradiction here. There are lots of presentational
attributes in XUL. It would be a bit clearer if there were fewer,
especially since a lot of them map directly into CSS and the mapping is
often non-obvious (e.g. different names for the attribute and CSS property).
>>> For XUL I would prefer a markup based solution with a script api (and
>>> such that the script api can be used without requiring markup as well).
>>
>> I really want to avoid creating a third, non-standard, chrome-only
>> animation API.
>
> You're confused. We don't have any animation APIs at the moment. The
> Apple feature isn't a standard either, if that's what you're referring to.
I think you pretty much misunderstood what roc said.
> I'm not particularly interested in what web sites want. I'm interested
> in animation needs for the UI (Firefox for example). If web
> specifications do not meet the requirements of the UI, then we should
> implement other APIs that do.
Or better yet fix and then use the web APIs, since the whole point of
the web APIs is to allow web application UIs.
-Boris
Mike Beltzner
>> You could just set "height:0" before you insert the element and then
>> set "height:auto" to have it slide into view (for example).
>
> That's the naive answer that someone who hadn't thought of it would
> give. The notification bar animation doesn't change its height at
> any time.
Easy, tiger. The notication bar "grows" out of the top, so I can see
why someone might think that it was done with height manipulation. But
it's true that "sliding" doesn't mean the same thing as "revealing"
where an element is at height:0 and then grows into its appropriate
height. It's the difference between a filmstrip like frame movement
from left to right (sliding) and a Star Wars like "wipe" (growing),
really.
> As someone who spent quite a bit of time trying to get the
> notification bar to work, I would say that being able to write
> 'slide the bar in' rather than spending a day trying to work it out
> by hand would be a great benefit. This is quite likely why jQuery's
> api is 'slideDown' rather than 'adjustTheCSSHeightFrom0ToAuto'.
This is a solid point. One reason why OSX applications are filled with
such lovely physical transitions is that the CoreAnimation API makes
it easy to do things like slide a box from point A to point B. We need
to make sure that there are easy-to-use APIs here for XUL developers.
> I'm not particularly interested in what web sites want. I'm
> interested in animation needs for the UI (Firefox for example). If
> web specifications do not meet the requirements of the UI, then we
> should implement other APIs that do. By the way, since you seem to
> have already determined what animation apis you think should be used
> for the UI, could you post the requirements that you gathered from
> the UI and firefox teams for animation? You did do that right?
One could argue that he's doing it now. Everyone's got the best
intentions here, and Roc put forward the group's recommendations for
comment and feedback. Once we get clear of this code freeze, I'm sure
my group and some XUL developers could sit down and whip up a list of
requirements. Or just take a pass through the CoreAnimation stuff and
lift from there.
cheers,
mike
Neil Deakin
> On 4-Nov-08, at 6:19 AM, Neil Deakin wrote:
>
>>> You could just set "height:0" before you insert the element and then
>>> set "height:auto" to have it slide into view (for example).
>>
>> That's the naive answer that someone who hadn't thought of it would
>> give. The notification bar animation doesn't change its height at any
>> time.
>
> Easy, tiger.
Sorry, I didn't mean that or my comment at the end to be in such a
strong tone and apologize for that. I was a bit disturbed by the
original message (and later messages) that seemed to imply that a
decision had already made to use the Apple css transition proposal
(which I don't like at all) for application UI without any discussion or
requirements.
rocal...@gmail.com
> rob...@ocallahan.org wrote:
> > SMIL will be available for DOM attributes, but really it would be
> > better if we didn't rely so much on presentational attributes in XUL.
>
> Wrong, XUL is a presentational language and all of the attributes are by
> definition presentational (or behavioural).
Fair enough. However, the presentational XUL attributes that you might
want to animate could be controlled by CSS as well --- in fact, I
think most already are.
> >> - a common usecase is to slide an element into view when it is inserted
> >> or removed from a document. No CSS propertes change in this case.
>
> > You could just set "height:0" before you insert the element and then
> > set "height:auto" to have it slide into view (for example).
>
> That's the naive answer that someone who hadn't thought of it would
> give. The notification bar animation doesn't change its height at any time.
I wasn't talking specifically about the notification bar there. Note
that JQuery's "slideDown" API works by manipulating heights.
> As someone who spent quite a bit of time trying to get the notification
> bar to work, I would say that being able to write 'slide the bar in'
> rather than spending a day trying to work it out by hand would be a
> great benefit. This is quite likely why jQuery's api is 'slideDown'
> rather than 'adjustTheCSSHeightFrom0ToAuto'.
I'd still like to know exactly what API you propose that would make
the notification bar problem easy, is general enough for your needs,
and is implementable.
> >> - the developer has little control over the behaviour of the animation.
> >> It happens automatically when any change is made.
>
> > That's true, but I don't think it will matter in practice.
>
> Usability depends very much on being precise.
>
> For instance what would happen if two notification bars need to appear
> at once? I haven't thought about that particular case here, but not
> being able to control what happens is not an effective way to build UI.
What behaviour do you want? If you want them to slide in as a unit,
put the notification bars in a single container and animate the reveal
of that container.
What CSS transitions can't do (easily) is control exactly which
changes to a particular property of a particular element are smoothed,
if there are multiple changes made by script. That's what I'm
skeptical will matter in practice.
> > Yes, but useful extensions would probably be rolled back into the
> > spec.
>
> You mean eight years from now?
It doesn't have to be that long.
Anyway, there's great synergy when we can use the same feature in
chrome and Web content; that generally requires a -moz prefix
initially. I never heard any demands for XUL elements to support an
'opacity' attribute because -moz-opacity was too long to type.
> > I really want to avoid creating a third, non-standard, chrome-only
> > animation API.
>
> You're confused. We don't have any animation APIs at the moment. The
> Apple feature isn't a standard either, if that's what you're referring to.
There is a draft spec for it and I think its chances of becoming a
real spec (with some modifications) are high. Obviously Apple has an
implementation and Opera apparently is positive on it too. So I think
we should implement it even if it's rejected for chrome.
> I'm not particularly interested in what web sites want. I'm interested
> in animation needs for the UI (Firefox for example). If web
> specifications do not meet the requirements of the UI, then we should
> implement other APIs that do. By the way, since you seem to have already
> determined what animation apis you think should be used for the UI,
> could you post the requirements that you gathered from the UI and
> firefox teams for animation? You did do that right?
To be honest, the meeting we had was not intended to resolve the
question of what APIs chrome needs. The meeting was focused on the
needs of Web content and how much we should implement of SMIL
Animation. We did agree that CSS transitions seems like a good fit for
Web UIs in general, certainly more so than SMIL Animation. And since
Web UIs and chrome UI probably want to do the same sorts of things, on
the face of it the same solutions should be applicable to both. Maybe
that's a bad assumption, but like I said in my reply to Beltzner, it's
an *assumption*.
So, I'm ready and willing to hear what the chrome use cases are,
especially those that aren't obviously addressed by CSS transitions. I
know about the notification bar difficulties, but it seems to me those
are more problems with the XUL box model.
Given you're happy with a script-driven solution, we should keep in
mind the option of just having a JS animation library for chrome. With
the JS animation support API that I mentioned earlier in this thread,
it should perform well. That sounds better than writing an equivalent
library in C++.
Rob
Jonas Sicking
Also note that we are not talking about performing the entire animation
from javascript. The animation can still be declared in SMIL, and then
started by a single javascript call.
/ Jonas
Jonas Sicking
No decisions have been made at all. We are in the process of testing the
various existing standards to see how well they fit with our
requirements, if they need tweaking or if they should be abandoned.
I do think there is a lot of overlap between the 'transition' type of
animations that we want in the UI in XUL and what pages want to do.
Specifically because a lot of pages contain UI as well. So if CSS
transitions don't work for us, they probably don't work for web pages
either.
I do think that the general approach of CSS transitions is very
interesting though. Specifically in its simplicity and in how well it
deals with overlapping animations. But if they don't work they don't
work and we need to find something else.
But I do think we should find something that integrates well with the
web platform though. Using the same mechanism for XUL UI and webpages
has a lot of values, both implementation wise and user wise.
/ Jonas
Cameron McCormack
>> But in reality, this "close" operation is rarely going to be
>> implemented entirely by an animation. Closing the window will
>> involve other behaviours, like saving state or changing layouts or
>> checking for unsaved data. And if you're going to have a "close
>> window" script (which will probably be invokable in several ways,
>> e.g. a close button and a command key), it may as well trigger the
>> animation. Then we don't have to repeat the list of commands that
>> can close a window.
>>
>> Basically I think it's going to be quite rare that you have input
>> that should *only* trigger an animation and have no other effect.
>> And if that's the case, providing convenient syntax for triggering
>> the animation isn't very useful.
OK, that's a reasonable argument for animations that always accompany
some other scripted behaviour. It'd be nice to know whether such
animations are more common than "decorative" ones where there's no
additional script (e.g. the mouseover zooming that Jeff Schiller uses on
the icons at the top of his blog (http://blog.codedread.com/), and would
benefit from the convenient syntax.
Jonas Sicking wrote:
> Also note that we are not talking about performing the entire
> animation from javascript. The animation can still be declared in
> SMIL, and then started by a single javascript call.
Right.
rocal...@gmail.com
> Robert O'Callahan:
> OK, that's a reasonable argument for animations that always accompany
> some other scripted behaviour. It'd be nice to know whether such
> animations are more common than "decorative" ones where there's no
> additional script (e.g. the mouseover zooming that Jeff Schiller uses on
> the icons at the top of his blog (http://blog.codedread.com/), and would
> benefit from the convenient syntax.
CSS transitions are good for :hover-driven animations. (But not for
SVG perhaps, due to the inability to animate attributes.)
I can't think of any situations where you'd want an access key or
mouse button press to trigger a purely decorative animation, except if
you wanted to use SMIL to animate the button on a script-less form
submission. Which seems fairly unlikely.
But OK, hover animations in SVG content seems like a valid use case.
I'm dubious whether it justifies the feature.
What might be nice is an API on elements, say "doAnimations()", that
does beginElement() (that seems like a bad name, by the way) on all
child <animation> elements. Then you could just write
<rect onclick="this.doAnimations()" ...>
<animate .../>
</rect>
Rob
Mark Finkle
wrote:
> So, I'm ready and willing to hear what the chrome use cases are,
> especially those that aren't obviously addressed by CSS transitions. I
> know about the notification bar difficulties, but it seems to me those
> are more problems with the XUL box model.
I thought I'd write down some current uses of animation in chrome:
* Notification bar display (already covered this one)
* Tab and button "throbbing" or "glowing" (cycling color changes) used
in the FF tabstrip
* Animated scrolling for tabstrip
* Animated reveal of the All-Tabs box
* Growing window reveal / Slide up used in the nsIAlertService window
display
* Growing reveal animation and disappearing toolbars for FullScreen
* Growing reveal for preferences window
* Fade in/out for video controls
Other potential uses include:
* Mouse-over slide out reveal for sidebars
* Fade in/out or other reveals for floating <panel>
* Slide left/right UI transitions (like iPhone)
I didn't stop to consider if a CSS API or JS API would be more
appropriate. This is just a list of uses cases.
Mike Beltzner
> I thought I'd write down some current uses of animation in chrome:
> * Notification bar display (already covered this one)
> * Tab and button "throbbing" or "glowing" (cycling color changes) used
> in the FF tabstrip
> * Animated scrolling for tabstrip
> * Animated reveal of the All-Tabs box
> * Growing window reveal / Slide up used in the nsIAlertService window
> display
> * Growing reveal animation and disappearing toolbars for FullScreen
> * Growing reveal for preferences window
> * Fade in/out for video controls
* action when an illegal drag target is chosen (animated by the OS,
but still)
> Other potential uses include:
> * Mouse-over slide out reveal for sidebars
> * Fade in/out or other reveals for floating <panel>
> * Slide left/right UI transitions (like iPhone)
* smooth tab re-ordering (like Adium)
* control fade-through (site icon fading through throbber)
* "bounce" animations when scrolling to an edge
* fade-in on tooltips
* tabs that "grow" into being
* tabs that "shrink" out of existence
cheers,
mike
Alex Faaborg
>> * Mouse-over slide out reveal for sidebars
>> * Fade in/out or other reveals for floating <panel>
>> * Slide left/right UI transitions (like iPhone)
>
> * control fade-through (site icon fading through throbber)
> * "bounce" animations when scrolling to an edge
> * fade-in on tooltips
> * tabs that "grow" into being
> * tabs that "shrink" out of existence
I think one of the best uses of animation in Firefox chrome would be
toolbar customization. With our current interface it is initially
unclear how existing controls will change placement until after you
have released the mouse button and dropped in a new control. The
animations used in OS X apps for toolbar customization really make it
feel like you are directly manipulating the toolbar controls, and
changes occur as soon as you start to drag a new control into position.
More generally, any time we are drawing some kindof marker to show the
eventual placement of something, we should really be animating the
objects the user is manipulated, like with changing the order of items
on the bookmarks toolbar (and tabs, as beltzner mentions).
-Alex
On Nov 5, 2008, at 3:03 AM, Mike Beltzner wrote:
> On 4-Nov-08, at 5:29 PM, Mark Finkle wrote:
>
>> I thought I'd write down some current uses of animation in chrome:
>> * Notification bar display (already covered this one)
>> * Tab and button "throbbing" or "glowing" (cycling color changes)
>> used
>> in the FF tabstrip
>> * Animated scrolling for tabstrip
>> * Animated reveal of the All-Tabs box
>> * Growing window reveal / Slide up used in the nsIAlertService window
>> display
>> * Growing reveal animation and disappearing toolbars for FullScreen
>> * Growing reveal for preferences window
>> * Fade in/out for video controls
>
> * action when an illegal drag target is chosen (animated by the OS,
> but still)
>
>> Other potential uses include:
>> * Mouse-over slide out reveal for sidebars
>> * Fade in/out or other reveals for floating <panel>
>> * Slide left/right UI transitions (like iPhone)
>
> * smooth tab re-ordering (like Adium)
> * control fade-through (site icon fading through throbber)
> * "bounce" animations when scrolling to an edge
> * fade-in on tooltips
> * tabs that "grow" into being
> * tabs that "shrink" out of existence
>
> cheers,
> mike
>
>
David Ascher
>>> Other potential uses include:
>>> * Mouse-over slide out reveal for sidebars
>>> * Fade in/out or other reveals for floating <panel>
>>> * Slide left/right UI transitions (like iPhone)
>>
>> * control fade-through (site icon fading through throbber)
>> * "bounce" animations when scrolling to an edge
>> * fade-in on tooltips
>> * tabs that "grow" into being
>> * tabs that "shrink" out of existence
>
slides as the user dives from folders to message lists to conversation
views to message details. As well as combined fades/swaps as people
change the "detail level" for things like message headers. And more,
lots more...
--david