Getting computed/current style
in [JavaScript]
|
From: Eric Bednarz on 13 Mar 2010 07:39 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). 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 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. <http://bednarz.nl/tmp/relative/> 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 Encouraging start of my new hobby. :-) Pointers to any good in depth research on the general topic would be appreciated. [0] <http://www.w3.org/TR/CSS2/> Status of this document [1] <http://www.w3.org/TR/2008/REC-CSS2-20080411/>
From: David Mark on 13 Mar 2010 09:12 Eric Bednarz wrote: > 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. > > <http://bednarz.nl/tmp/relative/> 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.
From: David Mark on 13 Mar 2010 09:24 David Mark wrote: > Eric Bednarz wrote: >> 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. > >> <http://bednarz.nl/tmp/relative/> > > 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. > I just glanced at the one for positions and it is a little more involved that the simple example given, but that's mostly because (at the time) I didn't want it to go through the on-the-fly testing if it didn't have to. So there is a feature test for broken position reporting (which is likely not comprehensive) and some other checks to skip some known problem cases. I should really just simplify it to do the same thing in all cases as _getting_ the styles doesn't have to be quick. I also see you are trying to get the right and bottom styles. That I would advise against and animate the size instead. But given some thought, if that's the abstraction you really want, I think you can determine those with similar techniques.
From: David Mark on 13 Mar 2010 09:42 David Mark wrote: > David Mark wrote: >> Eric Bednarz wrote: >>> 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. >> >>> <http://bednarz.nl/tmp/relative/> >> 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. >> > > I just glanced at the one for positions and it is a little more involved > that the simple example given, but that's mostly because (at the time) I > didn't want it to go through the on-the-fly testing if it didn't have > to. So there is a feature test for broken position reporting (which is > likely not comprehensive) and some other checks to skip some known > problem cases. I should really just simplify it to do the same thing in > all cases as _getting_ the styles doesn't have to be quick. > I see there is also some additional screwiness in there for determining hypothetical styles for inline elements (i.e. what would be its style if it were positioned). So this is not a pure position reporting function. IIRC, the point of this added complexity was for determining the styles needed for a positioned overlay. So I definitely think a simplified version based on the example I posted will serve you better than that function. It's a common theme in My Library that some functions are too complex for their own good. I'm making a note to break that one in two (one for getting true positions and another to determine positions for aspiring overlays).
From: Jorge on 13 Mar 2010 10:00
On Mar 13, 1:39 pm, Eric Bednarz <bedn...(a)fahr-zur-hoelle.org> wrote: > (...) > Pointers to any good in depth research on the general topic would be > appreciated. Whenever I have wanted to obtain the actual position of an element I have used .offset[Top,Left,Height,Width] rather than getComputedStyle. -- Jorge. |