Eric said:
As a side effect of looking into browser-scripting animations I recently
started to look into retrieving CSS values with script (I do agree that
the start values of an animation should ideally be set automatically).
In many cases, yes. There are three types of animations in My Library:
those that work as transitions (i.e. as effects options for
showElement), those that don't (e.g. the "move" effect) and those that
are dual-purpose (e.g. the "grow" effect). The latter two have to
determine their starting points. Though they are as general purpose in
this task as they come, it is a better idea to know the contexts that
work and design with those in mind.
Some styles are easier animate cross-browser than others. My latest
add-on/example, which I am polishing up today creates effects using CSS3
transform styles and was fairly challenging to get working
cross-browser. Some of my older animations (dating back to the IE4
days) use the clip style extensively, but are strictly transitional
effects (e.g. "slide"), so there was never any need to determine
starting points for those.
I've noticed that many libraries go with a kitchen sink approach and
attempt with a single effect that ostensibly animates any style. I've
always considered that to be a mistake (particularly for performance).
The CSS3 stuff I am working was inspired by Dojo's recent botched
attempt to leverage "complex styles" (e.g. clip, transforms) to create
some new "wowie" effects with their already botched animation mechanism.
They went the kitchen sink route, which ensures that calculating
starting points will be impossible.
Incidentally, the entity known as inappropriate to cite other than as
work in progress[0] but encouraged to be referenced by the entity formerly
known as the specification/recommendation[1] says:
“Note. Dynamic movement of relatively positioned boxes can produce
animation effects in scripting environments […]â€
<
http://www.w3.org/TR/CSS2/visuren.html> 9.4.3
Not sure what relative positioning has to do with it.
Since I never attempted to retrieve offset values of relatively
positioned elements by script, I wrote a little test case. I included
a column for a popular general purpose library to see if there’s any
magic bullet catch provided.
In general, relative positions would be the last thing I would want to
animate as the elements' movement often affects surrounding elements
(and in the worst case, the entire document). But in certain contexts
they can be useful.
Yes, they can be a pain to retrieve as well.
To my surprise the results are actually even worse than I expected. Some
notable observations:
- the only browser I could find that returns useful results is Firefox
3.6 (with the exception of resolving conflicts)
- Opera is totally broken
- jQuery does nothing more than returning the wrong results provided by the
getComputedStyle/currentStyle branch
Of course. If you use getElementPositionStyle in My Library, you should
have much better luck. For dimensions, getElementSizeStyle.
Encouraging start of my new hobby.
Why aren't you using My Library?
By coincidence, give me a day or
two and I will have a useful set of examples up that demonstrates how to
create custom effects for it. In creating the Transform add-on's
demonstration page, I refreshed my own memory of how my (somewhat
ancient and some might say primitive) effects mechanisms work and
decided it would be a good idea to share how the new add-on was created,
how it can be used and _most importantly_ how it compares to previously
created effects (e.g. the transition vs. non-transition vs. dual-purpose
concept). It will include copy and paste code snippets (some
dynamically generated) and also a primer on the alert and scrolling
anchors add-ons (the latter of which uses scrolling effects, which fall
into the non-transition category).
Pointers to any good in depth research on the general topic would be
appreciated.
Here's the thing. You can make use of offsetLeft/Top to check your
work. For instance, take your relative position quandary. Note that
you should not do this with elements that have 'none' as their display
style. This should be obvious and My Library makes no attempt to shield
you from such a mistake. Other libraries will go to a lot of trouble to
display, calculate and re-hide the element in this case, but I've always
considered that a mistake (if your app is trying to determine the size
or position of an element that is not part of the layout, then it
clearly has gaps in its logic that should be exposed rather than
spackled over). Sorry to wander off in that direction, but I recently
had somebody claim mine was "broken" because of this behavior.
So
back to the thing at hand, grab the offsetLeft and offsetTop (verify
beforehand that they are available and numbers of course) then set the
left and top styles to those. Simply put:-
var offsetLeft = el.offsetLeft;
var offsetTop = el.offsetTop;
el.style.left = offsetLeft + 'px';
el.style.top = offsetTop + 'px';
And now for the cunning bit. Compare the new offsetLeft/Top property
values to the old. If they are the same, you "guessed" right. If they
are off, vive la difference!
That's basically it. You can do sizes in the exact same way. If you
think about it, there are several others (e.g. margins) that can be
determined in similar fashion. But then there are a ton of styles that
cannot be determined in any way but to deal with the computed/current
style mess and that's why context is often key to these things (i.e. you
can save yourself a lot of trouble if you consider the issues in your
CSS design). That's why I don't like GP effects (or GP anything for
that matter).
I've tested this and similar techniques in a heart-stopping number of
browsers and have never been surprised by the fact that it works in
virtually all of them.
HTH.
