Getting computed/current style

Discussion in 'Javascript' started by Eric Bednarz, Mar 13, 2010.

  1. Eric Bednarz

    Eric Bednarz Guest

    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/>
     
    Eric Bednarz, Mar 13, 2010
    #1
    1. Advertising

  2. Eric Bednarz

    David Mark Guest

    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.
     
    David Mark, Mar 13, 2010
    #2
    1. Advertising

  3. Eric Bednarz

    David Mark Guest

    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.
     
    David Mark, Mar 13, 2010
    #3
  4. Eric Bednarz

    David Mark Guest

    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).
     
    David Mark, Mar 13, 2010
    #4
  5. Eric Bednarz

    Jorge Guest

    On Mar 13, 1:39 pm, Eric Bednarz <> 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.
     
    Jorge, Mar 13, 2010
    #5
  6. Eric Bednarz

    David Mark Guest

    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.
    >
    > <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
    >


    I notice in FF3.6 that all is as expected until box #6, where the right
    style is declared as 1px, expected to be computed as "-1px" and the
    browser returns "1px" instead. Realize that the "computed" styles
    offered by browsers have historically differed from what the
    specification calls computed. Regardless, this is a case where the
    specification semantics are irrelevant. The results are only wrong (in
    a practical sense) if setting the respective styles to the retrieved
    values changes the position (or size) of the box (which you will likely
    find doesn't happen very often). That gets back to the techniques I
    mentioned in the other post. For the right (as opposed to left)
    position, the acid test should be something like:-

    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
    }
    }

    A one-off feature test should not be too difficult. But again, I would
    stick to animating height/width and forget about right/bottom as those
    two have always been notably screwy cross-browser (e.g. some browsers
    don't even render them properly).
     
    David Mark, Mar 13, 2010
    #6
  7. Eric Bednarz

    David Mark Guest

    Jorge wrote:
    > On Mar 13, 1:39 pm, Eric Bednarz <> 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.


    But that is perfectly useless for animations in many cases as you can't
    set those. ;)
     
    David Mark, Mar 13, 2010
    #7
  8. Eric Bednarz

    Jorge Guest

    On Mar 13, 4:02 pm, David Mark <> wrote:
    > Jorge wrote:
    > > Whenever I have wanted to obtain the actual position of an element I
    > > have used .offset[Top,Left,Height,Width] rather than getComputedStyle.

    >
    > But that is perfectly useless for animations in many cases as you can't
    > set those.  ;)


    I said "to obtain" not "to set", David Mark. :)
    --
    Jorge.
     
    Jorge, Mar 13, 2010
    #8
  9. Eric Bednarz

    David Mark Guest

    Jorge wrote:
    > On Mar 13, 4:02 pm, David Mark <> wrote:
    >> Jorge wrote:
    >>> Whenever I have wanted to obtain the actual position of an element I
    >>> have used .offset[Top,Left,Height,Width] rather than getComputedStyle.

    >> But that is perfectly useless for animations in many cases as you can't
    >> set those. ;)

    >
    > I said "to obtain" not "to set", David Mark. :)


    Which has no bearing on this discussion, "Jorge". :(
     
    David Mark, Mar 13, 2010
    #9
  10. 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/
     
    Garrett Smith, Mar 14, 2010
    #10
  11. Eric Bednarz

    David Mark Guest

    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.
     
    David Mark, Mar 14, 2010
    #11
  12. Eric Bednarz

    David Mark Guest

    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
     
    David Mark, Mar 14, 2010
    #12
  13. 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/
     
    Garrett Smith, Mar 18, 2010
    #13
  14. Eric Bednarz

    David Mark Guest

    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).
     
    David Mark, Mar 18, 2010
    #14
  15. Eric Bednarz

    David Mark Guest

    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.
     
    David Mark, Mar 18, 2010
    #15
  16. Eric Bednarz

    David Mark Guest

    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
     
    David Mark, Mar 18, 2010
    #16
  17. 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/
     
    Garrett Smith, Mar 19, 2010
    #17
  18. Eric Bednarz

    David Mark Guest

    Garrett Smith wrote:
    > 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]
    >


    You truly are hopeless. You really should be following me ("cinsoft" on
    Twitter). Good luck with the FAQ. :)
     
    David Mark, Mar 19, 2010
    #18
  19. David Mark wrote:
    > Garrett Smith wrote:
    >> 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]
    >>

    >
    > You truly are hopeless. You really should be following me ("cinsoft" on
    > Twitter). Good luck with the FAQ. :)

    I don't have much interest in following someone who cannot explain the
    reason for his own code (but keep up the marketing and you're bound to
    get some fool who will).
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Mar 19, 2010
    #19
  20. Eric Bednarz

    David Mark Guest

    Garrett Smith wrote:
    > David Mark wrote:
    >> Garrett Smith wrote:
    >>> 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]
    >>>

    >>
    >> You truly are hopeless. You really should be following me ("cinsoft" on
    >> Twitter). Good luck with the FAQ. :)

    > I don't have much interest in following someone who cannot explain the
    > reason for his own code (but keep up the marketing and you're bound to
    > get some fool who will).


    Once again, you are blind. Good luck with that!
     
    David Mark, Mar 19, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hardeep Rakhra
    Replies:
    8
    Views:
    656
    Hardeep Rakhra
    Jan 15, 2004
  2. Nik Coughlin
    Replies:
    2
    Views:
    194
    Nik Coughlin
    Jan 23, 2008
  3. dhtml
    Replies:
    6
    Views:
    233
    dhtml
    Apr 3, 2008
  4. liketofindoutwhy

    getting computed style for Img width and height

    liketofindoutwhy, Apr 23, 2008, in forum: Javascript
    Replies:
    2
    Views:
    209
    liketofindoutwhy
    Apr 24, 2008
  5. Chris Riesbeck

    getting computed clip rect

    Chris Riesbeck, Jul 15, 2008, in forum: Javascript
    Replies:
    31
    Views:
    357
    Laurent vilday
    Jul 16, 2008
Loading...

Share This Page