Getting computed/current style
in [JavaScript]
|
From: Eric Bednarz on 13 Mar 2010 18:15 David Mark <dmark.cinsoft(a)gmail.com> writes: > Eric Bednarz wrote: > 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). I have always considered a generic function to retrieve CSS values an unrealistic idea because even superficial examination should reveal fundamental problems; on the other hand, I never went past superficial examination. One thing that I probably should have emphasized stronger is that I am not attempting to solve some particular problem. There is some pretense among some libraries to provide a generic CSS getter; that strikes me more as generic naivity, but I'm also curious (and of course I'd like to have one). >> “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. Neither am I, they are the ones bringing it up in only that context ;-) But since the offsets of relative positioning have some extra gotchas, I thought it would make an interesting case. I've read the rest of this and the other posts and I'll try to get back to it when I have a bit more time, thanks so far (I don't want to look like a runaway-OP :-).
From: David Mark on 13 Mar 2010 18:22 Eric Bednarz wrote: > David Mark <dmark.cinsoft(a)gmail.com> writes: > >> Eric Bednarz wrote: > >> 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). > > I have always considered a generic function to retrieve CSS values an > unrealistic idea because even superficial examination should reveal > fundamental problems; on the other hand, I never went past superficial > examination. > > One thing that I probably should have emphasized stronger is that I am > not attempting to solve some particular problem. There is some pretense > among some libraries to provide a generic CSS getter; that strikes me > more as generic naivity, but I'm also curious (and of course I'd like to > have one). Not sure why you would like to have one (other than curiosity). As for a particular problem, I gathered that you wanted to get starting points for animations. > >>> “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. > > Neither am I, they are the ones bringing it up in only that context ;-) It's a strangely worded note, that's for sure. > But since the offsets of relative positioning have some extra gotchas, > I thought it would make an interesting case. Yes. But the offset* trick is a great leveler. > > I've read the rest of this and the other posts and I'll try to get back > to it when I have a bit more time, thanks so far (I don't want to look > like a runaway-OP :-). NP. I'll have my Examples page up soon (likely before the weekend is out). If you are interested in creating animations (and don't mind using a library), it should also be helpful to you.
From: Garrett Smith on 14 Mar 2010 04:25 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). > > 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. > "Offset" values and top/left style values are different things. Offset", to me, is about the badly defined and highly inconsistent "offsetTop", "offsetLeft", and "offsetParent". These properties are different in IE8, IE7, IE6, Safari 4, Safari 3, Safari 2, and so on. For every major browser version, there is a different meaning to offsetTop. So take 5 browsers and take the latest 3 versions, that is a total of 15 different implementations of offsetTop. I think of animation as being a transition from one state to another in a given amount of time. That transition is a dynamic abstraction, and so if we are talking about animation css style properties, then the animation would not use offsets, but would use style properties. > <http://bednarz.nl/tmp/relative/> > FWIS, the code appends relatively positioned children to an BODY that, in most modern browsers, will have a margin. What I do not understand is the "expected" column. What are the expectations coming from? > 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 > To retrieve element coordinate offsets with jQuery, jQuery's offset method would be the method for that. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 14 Mar 2010 05:02 Garrett Smith 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). >> >> 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. >> > > "Offset" values and top/left style values are different things. Offset", > to me, is about the badly defined and highly inconsistent "offsetTop", > "offsetLeft", and "offsetParent". These properties are different in IE8, > IE7, IE6, Safari 4, Safari 3, Safari 2, and so on. For every major > browser version, there is a different meaning to offsetTop. So take 5 > browsers and take the latest 3 versions, that is a total of 15 different > implementations of offsetTop. Do you still not understand bow my solution to this problem works? We've been over this. It doesn't matter how those properties differ per browser. That's a red herring. What does matter is how they differ on manipulating the CSS. It's about relatives, not absolutes (and I'm not talking about the position styles). ;) > > I think of animation as being a transition from one state to another in > a given amount of time. That's what they are. Though I often use the term "transition" to describe a subset of my effects that relate to showing and hiding elements. I suppose that could be confusing and will have to think about that as I update the effects documentation for My Library. > > That transition is a dynamic abstraction, and so if we are talking about > animation css style properties, then the animation would not use > offsets, but would use style properties. Of course. As mentioned to "Jorge", you sure as hell can't set the offset* properties. They are strictly used to determine required adjustments to certain styles. > >> <http://bednarz.nl/tmp/relative/> >> > > FWIS, the code appends relatively positioned children to an BODY that, > in most modern browsers, will have a margin. > > What I do not understand is the "expected" column. What are the > expectations coming from? The specs I imagine; which, as mentioned, are fairly irrelevant to the task. What matters is the identity tests (e.g. if you set a style to its retrieved computed/cascaded style *does it change*. That's the basic concept and it is very powerful if you can grasp it. > >> 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 >> > > To retrieve element coordinate offsets with jQuery, jQuery's offset > method would be the method for that. That's another red herring. The absolute position has nothing to do with it. Try setting the style left/top properties based on _that_ and you will find that you have nothing close to a GP solution.
From: David Mark on 14 Mar 2010 08:13
David Mark wrote: > Garrett Smith 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). >>> >>> 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. >>> >> "Offset" values and top/left style values are different things. Offset", >> to me, is about the badly defined and highly inconsistent "offsetTop", >> "offsetLeft", and "offsetParent". These properties are different in IE8, >> IE7, IE6, Safari 4, Safari 3, Safari 2, and so on. For every major >> browser version, there is a different meaning to offsetTop. So take 5 >> browsers and take the latest 3 versions, that is a total of 15 different >> implementations of offsetTop. > > Do you still not understand bow my solution to this problem works? > We've been over this. It doesn't matter how those properties differ per > browser. That's a red herring. What does matter is how they differ on > manipulating the CSS. It's about relatives, not absolutes (and I'm not > talking about the position styles). ;) > Matter of fact, I am tired of this basic idea (among others) being obscured by off-track comments about offset* properties. It's positively maddening. The described technique is useful for animations, drag and drop or any time you need to get these styles such that they *will not change the box* on setting them back. It has _nothing_ to do with what the specs say about "computed" styles or the lack of formal specs (or consistent cross-browser behavior) for the offset* properties. All inconsistencies are *factored out* of the equation by design. <FAQENTRY> How do I get the current left/top/right/bottom/height/width/etc. styles? I think I've explained the concept enough times. It's staggeringly simple (which is why it works). Shouldn't take ten minutes to write an entry explaining it and sample code. But I'm not writing a word of it (more than I already have) until it is confirmed that the FAQ maintainer understands the underlying ideas. On a related note, that viewport measurement entry is long past due for an update as well. I've demonstrated the basic generic feature test (as opposed to the "quirkaround" found in the current entry. The explanation needs to be changed as well. http://www.cinsoft.net/viewport.asp |