Getting computed/current style
in [JavaScript]
|
From: Garrett Smith on 17 Mar 2010 23:01 David Mark wrote: > 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. >>>> Reading the spec and writing tests is probably better use of time than learning a library that does it. >>> "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? No. >> We've been over this. I recall you posted a concept in "getComputedStyle Where is My LI", but as explained there (repeatedly, IIRC), that concept would fail in some cases. 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. > I fail to see how offset coordinates are useful for animations. For animations, one or more style properties will vary over the course of the transition, and the transition is best if written as time-based. Although offsetTop/Left may happen to be the same as CSS left top values, they are not a corollary. offsetLeft/Top may include margin, padding, and or border, and may be magic for the root element in various ways depending on browser and version. In order to use these properties, it is important to understand the consequences of what happens in what situation. They may "work" in a given situation, but how they perform in other another situation will varies. > <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. > I'm not sure that I understand your idea. I fail to see what setting style.right have to do with offsetWidth. A function that returns a string value or null is intransitive. The null check `rightStyle !== null` could be avoided by having function `yourComputedStyleWrapper` always return a string value. | var offsetWidth = el.offsetWidth; | var rightStyle = yourComputedStyleWrapper(el, 'right'); | | if (rightStyle !== null) { | el.style.right = rightStyle; | | if (el.offsetWidth != offsetWidth) { | // Adjust expectations based on the difference | } | } Ideal solutions are simple, but a solution that is simple does not necessarily work. does not guarantee that something will work. > 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 How is that related? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 18 Mar 2010 06:58 Garrett Smith wrote: > David Mark wrote: >> 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. >>>>> > > Reading the spec and writing tests is probably better use of time than > learning a library that does it. Or, just understand some basic equations... The specs are irrelevant and tests should just confirm your equations are genuine. > >>>> "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? > > No. Oh for Christ's sake. Really?! > >>> We've been over this. > > I recall you posted a concept in "getComputedStyle Where is My LI", but > as explained there (repeatedly, IIRC), that concept would fail in some > cases. No, you are just not seeing the forest for the trees (as happened last time we had this discussion). Is anyone else confused by what I mean by "checking your work" with offset* properties? > > 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. >> > > I fail to see how offset coordinates are useful for animations. Yes, you fail. > For > animations, one or more style properties will vary over the course of > the transition, and the transition is best if written as time-based. What does that have to do with the price of beans in Somalia? We are talking about finding the *initial* styles when they are either unavailable (often in IE) or you simply want to make sure they are correct to the pixel (rather than assuming that the browsers' often "computed" styles are bug-free). > > Although offsetTop/Left may happen to be the same as CSS left top > values, they are not a corollary. Here you go again. You are going off in the weeds. Stop and think about what I wrote. > offsetLeft/Top may include margin, > padding, and or border, and may be magic for the root element in various > ways depending on browser and version. In order to use these properties, > it is important to understand the consequences of what happens in what > situation. Nope. The differences are irrelevant for this example. They are *factored out* of the equations. > > They may "work" in a given situation, but how they perform in other > another situation will varies. You just don't get what I'm saying and I'm tired of trying to explain it to you. Hopefully the OP has an easier time with the concepts. > >> <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. >> > > I'm not sure that I understand your idea. I know you don't and it absolutely drives me nuts. > > I fail to see what setting style.right have to do with offsetWidth. I never use the - right - position, but ISTM that setting it will affect the width of the element. > > A function that returns a string value or null is intransitive. Stop and consider the simpler case of left/top and perhaps you will get it. > > The null check `rightStyle !== null` could be avoided by having function > `yourComputedStyleWrapper` always return a string value. That's beside the point (and contrary to the way computed style methods work). > > | var offsetWidth = el.offsetWidth; > | var rightStyle = yourComputedStyleWrapper(el, 'right'); > | > | if (rightStyle !== null) { > | el.style.right = rightStyle; > | > | if (el.offsetWidth != offsetWidth) { > | // Adjust expectations based on the difference > | } > | } > > Ideal solutions are simple, but a solution that is simple does not > necessarily work. does not guarantee that something will work. No kidding. Just so happens that _this_ simple solution does work (at least I can vouch for left/top/height/width without question). YMMV with right/bottom. > >> 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 > > How is that related? > Related to you burying my (often simple) feature testing ideas in a bunch of unrelated specification quoting and other confusion (which results in nothing getting settled in the FAQ).
From: David Mark on 18 Mar 2010 08:08 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> 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. >>>>>> >> Reading the spec and writing tests is probably better use of time than >> learning a library that does it. > > Or, just understand some basic equations... The specs are irrelevant > and tests should just confirm your equations are genuine. > >>>>> "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? >> No. > > Oh for Christ's sake. Really?! > >>>> We've been over this. >> I recall you posted a concept in "getComputedStyle Where is My LI", but >> as explained there (repeatedly, IIRC), that concept would fail in some >> cases. > > No, you are just not seeing the forest for the trees (as happened last > time we had this discussion). Is anyone else confused by what I mean by > "checking your work" with offset* properties? > >> 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. >>> >> I fail to see how offset coordinates are useful for animations. > > Yes, you fail. > >> For >> animations, one or more style properties will vary over the course of >> the transition, and the transition is best if written as time-based. > > What does that have to do with the price of beans in Somalia? We are > talking about finding the *initial* styles when they are either > unavailable (often in IE) or you simply want to make sure they are > correct to the pixel (rather than assuming that the browsers' often > "computed" styles are bug-free). > >> Although offsetTop/Left may happen to be the same as CSS left top >> values, they are not a corollary. > > Here you go again. You are going off in the weeds. Stop and think > about what I wrote. > >> offsetLeft/Top may include margin, >> padding, and or border, and may be magic for the root element in various >> ways depending on browser and version. In order to use these properties, >> it is important to understand the consequences of what happens in what >> situation. > > Nope. The differences are irrelevant for this example. They are > *factored out* of the equations. > >> They may "work" in a given situation, but how they perform in other >> another situation will varies. > > You just don't get what I'm saying and I'm tired of trying to explain it > to you. Hopefully the OP has an easier time with the concepts. > >>> <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. >>> >> I'm not sure that I understand your idea. > > I know you don't and it absolutely drives me nuts. > >> I fail to see what setting style.right have to do with offsetWidth. > > I never use the - right - position, but ISTM that setting it will affect > the width of the element. > >> A function that returns a string value or null is intransitive. > > Stop and consider the simpler case of left/top and perhaps you will get it. > >> The null check `rightStyle !== null` could be avoided by having function >> `yourComputedStyleWrapper` always return a string value. > > That's beside the point (and contrary to the way computed style methods > work). > >> | var offsetWidth = el.offsetWidth; >> | var rightStyle = yourComputedStyleWrapper(el, 'right'); >> | >> | if (rightStyle !== null) { >> | el.style.right = rightStyle; >> | >> | if (el.offsetWidth != offsetWidth) { >> | // Adjust expectations based on the difference >> | } >> | } >> >> Ideal solutions are simple, but a solution that is simple does not >> necessarily work. does not guarantee that something will work. > > No kidding. Just so happens that _this_ simple solution does work (at > least I can vouch for left/top/height/width without question). YMMV > with right/bottom. > >>> 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 >> How is that related? >> > > Related to you burying my (often simple) feature testing ideas in a > bunch of unrelated specification quoting and other confusion (which > results in nothing getting settled in the FAQ). What the hell. I will try one more time to explain the computed style trick. God knows, I have nothing better to do but repeat the same simple concepts over and over. If you have offsetLeft/Top properties that are numbers you can:- 1. Store them in variables 2. Set the left/top styles to the same (in pixels) 3. Check to see if the offsetLeft/Top properties *changed* Now, if they didn't change, you've got your start points and can proceed with the animation (or drag or overlay or whatever) without taking any further action. If they did change, what do you suppose your next action should be? I know I'll regret this, but I'm leaving that as an exercise. And any mention of the word "intransitive" or citing anything in the specifications will mean an automatic failure. And don't bother peeking at My Library either; as mentioned, its rendition of this is too complicated for its own good.
From: David Mark on 18 Mar 2010 17:31 David Mark wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> 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. >>>>>>> >>> Reading the spec and writing tests is probably better use of time than >>> learning a library that does it. >> Or, just understand some basic equations... The specs are irrelevant >> and tests should just confirm your equations are genuine. >> >>>>>> "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? >>> No. >> Oh for Christ's sake. Really?! >> >>>>> We've been over this. >>> I recall you posted a concept in "getComputedStyle Where is My LI", but >>> as explained there (repeatedly, IIRC), that concept would fail in some >>> cases. >> No, you are just not seeing the forest for the trees (as happened last >> time we had this discussion). Is anyone else confused by what I mean by >> "checking your work" with offset* properties? >> >>> 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. >>>> >>> I fail to see how offset coordinates are useful for animations. >> Yes, you fail. >> >>> For >>> animations, one or more style properties will vary over the course of >>> the transition, and the transition is best if written as time-based. >> What does that have to do with the price of beans in Somalia? We are >> talking about finding the *initial* styles when they are either >> unavailable (often in IE) or you simply want to make sure they are >> correct to the pixel (rather than assuming that the browsers' often >> "computed" styles are bug-free). >> >>> Although offsetTop/Left may happen to be the same as CSS left top >>> values, they are not a corollary. >> Here you go again. You are going off in the weeds. Stop and think >> about what I wrote. >> >>> offsetLeft/Top may include margin, >>> padding, and or border, and may be magic for the root element in various >>> ways depending on browser and version. In order to use these properties, >>> it is important to understand the consequences of what happens in what >>> situation. >> Nope. The differences are irrelevant for this example. They are >> *factored out* of the equations. >> >>> They may "work" in a given situation, but how they perform in other >>> another situation will varies. >> You just don't get what I'm saying and I'm tired of trying to explain it >> to you. Hopefully the OP has an easier time with the concepts. >> >>>> <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. >>>> >>> I'm not sure that I understand your idea. >> I know you don't and it absolutely drives me nuts. >> >>> I fail to see what setting style.right have to do with offsetWidth. >> I never use the - right - position, but ISTM that setting it will affect >> the width of the element. I should clarify this. Throughout I have been referring to the case of right/bottom set _in addition to_ left/top. But if left/top are auto, then right/bottom are just as trivial to compute as left/top. It is the case where _both_ sides (e.g. left and right) are set to something other than auto that dimensions come into play. That is a very odd case and should not be used as some browsers won't render it properly anyway (just document that it is to be avoided). Instead, set left/top and height/width to achieve the same box. >> >>> A function that returns a string value or null is intransitive. >> Stop and consider the simpler case of left/top and perhaps you will get it. >> >>> The null check `rightStyle !== null` could be avoided by having function >>> `yourComputedStyleWrapper` always return a string value. >> That's beside the point (and contrary to the way computed style methods >> work). >> >>> | var offsetWidth = el.offsetWidth; >>> | var rightStyle = yourComputedStyleWrapper(el, 'right'); >>> | >>> | if (rightStyle !== null) { >>> | el.style.right = rightStyle; >>> | >>> | if (el.offsetWidth != offsetWidth) { >>> | // Adjust expectations based on the difference >>> | } >>> | } This addresses the odd case where left and right are set to something other than auto. >>> >>> Ideal solutions are simple, but a solution that is simple does not >>> necessarily work. does not guarantee that something will work. >> No kidding. Just so happens that _this_ simple solution does work (at >> least I can vouch for left/top/height/width without question). YMMV >> with right/bottom. But will only vary in the case where left/top are not auto. As counter-intuitive as it may seem, this will work fine for right/bottom if left/top are auto:- var offsetLeft = el.offsetLeft; el.style.right = offsetLeft + 'px'; if (el.offsetLeft != offsetLeft) { // Adjust according to difference (hint) } I don't think I've ever found the need to position an element (with script) by right/bottom. I've always found it more intuitive to calculate left/top, but I suppose I should add an option to my positionElement function to use the other sides as it would be simpler for some contexts (i.e. wouldn't have to subtract the height and/or width of the element to determine the destination position). HTH
From: Garrett Smith on 19 Mar 2010 01:41
David Mark wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: >>>>>> Eric Bednarz wrote: [snip a bunch of noise] > If you have offsetLeft/Top properties that are numbers you can:- > > 1. Store them in variables > 2. Set the left/top styles to the same (in pixels) > 3. Check to see if the offsetLeft/Top properties *changed* > > Now, if they didn't change, you've got your start points and can proceed > with the animation (or drag or overlay or whatever) without taking any > further action. > > If they did change, what do you suppose your next action should be? I > know I'll regret this, but I'm leaving that as an exercise. And any > mention of the word "intransitive" or citing anything in the > specifications will mean an automatic failure. And don't bother peeking > at My Library either; as mentioned, its rendition of this is too > complicated for its own good. Is there a point to any of this? Does this follow from what you wrote: "How do I get the current left/top/right/bottom/height/width/etc. styles?" -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |