Getting computed/current style
Eric Bednarz
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/>
David Mark
> 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
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
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).
Jorge
> (...)
> 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.
David Mark
> 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
But that is perfectly useless for animations in many cases as you can't
set those. ;)
Jorge
> 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.
David Mark
Which has no bearing on this discussion, "Jorge". :(
Hans-Georg Michna
>retrieving CSS values with script
The basics are here: http://winhlp.com/node/610#s
Hans-Georg
Eric Bednarz
> Eric Bednarz wrote:
> I've noticed that many libraries go with a kitchen sink approach and
> attempt with a single effect that ostensibly animates any style. I've
> always considered that to be a mistake (particularly for performance).
I have always considered a generic function to retrieve CSS values an
unrealistic idea because even superficial examination should reveal
fundamental problems; on the other hand, I never went past superficial
examination.
One thing that I probably should have emphasized stronger is that I am
not attempting to solve some particular problem. There is some pretense
among some libraries to provide a generic CSS getter; that strikes me
more as generic naivity, but I’m also curious (and of course I’d like to
have one).
>> “Note. Dynamic movement of relatively positioned boxes can produce
>> animation effects in scripting environments […]”
>> <http://www.w3.org/TR/CSS2/visuren.html> 9.4.3
>
> Not sure what relative positioning has to do with it.
Neither am I, they are the ones bringing it up in only that context ;-)
But since the offsets of relative positioning have some extra gotchas,
I thought it would make an interesting case.
I’ve read the rest of this and the other posts and I’ll try to get back
to it when I have a bit more time, thanks so far (I don’t want to look
like a runaway-OP :-).
David Mark
> David Mark <dmark....@gmail.com> writes:
>
>> Eric Bednarz wrote:
>
>> I've noticed that many libraries go with a kitchen sink approach and
>> attempt with a single effect that ostensibly animates any style. I've
>> always considered that to be a mistake (particularly for performance).
>
> I have always considered a generic function to retrieve CSS values an
> unrealistic idea because even superficial examination should reveal
> fundamental problems; on the other hand, I never went past superficial
> examination.
>
> One thing that I probably should have emphasized stronger is that I am
> not attempting to solve some particular problem. There is some pretense
> among some libraries to provide a generic CSS getter; that strikes me
> more as generic naivity, but I’m also curious (and of course I’d like to
> have one).
Not sure why you would like to have one (other than curiosity). As for
a particular problem, I gathered that you wanted to get starting points
for animations.
>
>>> “Note. Dynamic movement of relatively positioned boxes can produce
>>> animation effects in scripting environments […]”
>>> <http://www.w3.org/TR/CSS2/visuren.html> 9.4.3
>> Not sure what relative positioning has to do with it.
>
> Neither am I, they are the ones bringing it up in only that context ;-)
It's a strangely worded note, that's for sure.
> But since the offsets of relative positioning have some extra gotchas,
> I thought it would make an interesting case.
Yes. But the offset* trick is a great leveler.
>
> I’ve read the rest of this and the other posts and I’ll try to get back
> to it when I have a bit more time, thanks so far (I don’t want to look
> like a runaway-OP :-).
NP. I'll have my Examples page up soon (likely before the weekend is
out). If you are interested in creating animations (and don't mind
using a library), it should also be helpful to you.
Garrett Smith
> 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/
David Mark
> 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
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.
Garrett Smith
> 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?
David Mark
> 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
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
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
Garrett Smith
> 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?"
David Mark
> 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. :)
Garrett Smith
> 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. :)
reason for his own code (but keep up the marketing and you're bound to
get some fool who will).
David Mark
> 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!
Garrett Smith
You posted a suggestion to use offsetLeft and offsetTop to check the
work of setting top and left values. That sort of feature test cannot
work reliably, as offsetTop being nonstandard features that define what
would be the "expected" value.
| 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 test would be then expressed as `doesPositionStyleAffectOffset`.
Now if there is a point to performing such test, it has not been stated
by you nor by anyone else.
If there is no point to that code, then I would suggest it's removal
from wherever it exists.
It does not seem to answer your proposed question: "How do I get the
current left/top/right/bottom/height/width/etc. styles?"
Nor am I hopeless. Annoyed, yes, a little annoyed.
David Mark
> David Mark wrote:
>> 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!
> No, I am not blind.
You've been acting like you can't see the forest for the trees with
numerous suggestions of mine. It's been going on for years.
>
> You posted a suggestion to use offsetLeft and offsetTop to check the
> work of setting top and left values. That sort of feature test cannot
> work reliably, as offsetTop being nonstandard features that define what
> would be the "expected" value.
You still don't get it and I don't care. Dig a little deeper. Twitter
has the links you need (or just visit my home page). ;)
>
> | 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 test would be then expressed as `doesPositionStyleAffectOffset`.
> Now if there is a point to performing such test, it has not been stated
> by you nor by anyone else.
Wrong. We've had this discussion more than once. I've all but spelled
it out here. Now I have spelled it out (in code) on my site.
>
> If there is no point to that code, then I would suggest it's removal
> from wherever it exists.
You aren't in a position to suggest removing code you clearly don't
understand.
>
> It does not seem to answer your proposed question: "How do I get the
> current left/top/right/bottom/height/width/etc. styles?"
Asked and answered.
>
> Nor am I hopeless. Annoyed, yes, a little annoyed.
Join the club. Starting with isHostMethod, then viewport measurement
and now this (and many in between). I'm tired of revisiting the same
"arguments" over and over.
Garrett Smith
> Garrett Smith wrote:
>> David Mark wrote:
>>> 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!
>> No, I am not blind.
>
> You've been acting like you can't see the forest for the trees with
> numerous suggestions of mine. It's been going on for years.
>
[...]
>
> Wrong. We've had this discussion more than once. I've all but spelled
> it out here. Now I have spelled it out (in code) on my site.
>
As with Twitter: That is your business.
Although I find value in the *concept* of twitter, the UI is not worth
wrangling with. I have decided that it is not worth the frustration of
trying to use Twitter UI. I am just not that interested in broadcasting
to many people. I figure that the smart folks will find there way here
and the same folks who are promulgating the same bad practices that have
crap-flooded the industry with will flounder with their pop websites
(like Twitter).
Many of these individuals become millionaires by being involved in
trendy projects that sell. They sell despite the "engineering" with code
that seems incongruous with that term.
What happens here on c.l.js is public discussion. If there is a good
reason for that test, such as a case where it helps find style value in
a particular situation, I haven't seen anybody posting it.
>> If there is no point to that code, then I would suggest it's removal
>> from wherever it exists.
>
> You aren't in a position to suggest removing code you clearly don't
> understand.
>
No, c.l.js is the right place to discuss these things. You can advertise
your twitter homepage or website or library, but those are not places
for open discussion. Here, there is free discussion.
If I am missing a point (a good reason) for determining
`doesPositionStyleAffectOffset` or whatever it should be called, then it
hasn't been made clear what that is.
>> It does not seem to answer your proposed question: "How do I get the
>> current left/top/right/bottom/height/width/etc. styles?"
>
> Asked and answered.
>
The way to read styles is for browsers that implement ViewCSS, use
defaultView.getComputedStyle(obj, pseudoClass), and for IE, to use
currentStyle.
Both of those APIs are problematic. Some massaging is usually required,
both of the style values in the CSS and of the values returned, to get
consistent results.
This is an issue I've had to deal with a lot over the years and I do not
have a simple solution. You also suggested Eric to use "My Library" and
that is not going in the FAQ.
>> Nor am I hopeless. Annoyed, yes, a little annoyed.
>
> Join the club. Starting with isHostMethod, then viewport measurement
> and now this (and many in between). I'm tired of revisiting the same
> "arguments" over and over.
OK, I think I see where you're coming from. I looked at each argument
separately, not as the same thing.
I agree that there is value in having a good simple answer to the
question. The problem is that the question can't be answered so simply.
Reading style values is a simple thing to want to do but a general
solution to solve for that is not going to be simple.
David Mark
My point was I made the information available after the initial
confusion. You should keep up with my site anyway as it is full of
useful information.
>
> Although I find value in the *concept* of twitter, the UI is not worth
> wrangling with.
Yes, the Web UI is a jQuery. Enough said. :(
> I have decided that it is not worth the frustration of
> trying to use Twitter UI. I am just not that interested in broadcasting
> to many people.
That's your choice. I put up with it as it is great for generating
traffic, which begets more traffic, which begets contract offers. ;)
> I figure that the smart folks will find there way here
> and the same folks who are promulgating the same bad practices that have
> crap-flooded the industry with will flounder with their pop websites
> (like Twitter).
I figured that once too. People seem to gravitate to the crap-ola. If
it has pretty graphics, it must be good! :)
>
> Many of these individuals become millionaires by being involved in
> trendy projects that sell. They sell despite the "engineering" with code
> that seems incongruous with that term.
Yes. Take Google, which throws exceptions on virtually every page in
the _latest_ Opera (a very standards-compliant browser of course). It's
all browser sniffing madness.
>
> What happens here on c.l.js is public discussion. If there is a good
> reason for that test, such as a case where it helps find style value in
> a particular situation, I haven't seen anybody posting it.
That's because (like many of my points on feature testing), nobody seems
to have thought of it (except Richard of course, who I assume is amused
that I with what I have built on top of many of his original ideas).
>
>>> If there is no point to that code, then I would suggest it's removal
>>> from wherever it exists.
>>
>> You aren't in a position to suggest removing code you clearly don't
>> understand.
>>
>
> No, c.l.js is the right place to discuss these things. You can advertise
> your twitter homepage or website or library, but those are not places
> for open discussion. Here, there is free discussion.
I was just trying to point you to some example code that I posted.
>
> If I am missing a point (a good reason) for determining
> `doesPositionStyleAffectOffset` or whatever it should be called, then it
> hasn't been made clear what that is.
>
>>> It does not seem to answer your proposed question: "How do I get the
>>> current left/top/right/bottom/height/width/etc. styles?"
>>
>> Asked and answered.
>>
>
> The way to read styles is for browsers that implement ViewCSS, use
> defaultView.getComputedStyle(obj, pseudoClass), and for IE, to use
> currentStyle.
Not in many cases (e.g. left/top/right/bottom/height/width). First
there are lots of bugs, second IE won't return _anything_ unless there
is a corresponding declaration (and even then, it may not be in a
convenient format). That's why you have to balance the equation with
offset* properties. You don't have to take my word for it. Try out my
examples. I've tested in IE5.5-8 (all modes), Opera 7-10, FF1-3.6,
Chrome 3/4, Safari 4.0, an iPhone and several other odd agents. If you
get the equations right (which I knew I did for at least
left/top/height/width), you really can't go wrong (math is math).
Contrast that to what the "majors" do, which is often confused or even
completely backwards (e.g. jQuery's ridiculous "smoothing over" of box
model differences, which sometimes results in unusable dimensions).
Then there's that crazy MacGuyver hack, which I hate to say is actually
in My Library as well. Like I said, the simplified examples that I am
posting now (e.g. viewport, size, position, keyboard) will eventually
supplant the more complicated routines in My Library.
>
> Both of those APIs are problematic. Some massaging is usually required,
> both of the style values in the CSS and of the values returned, to get
> consistent results.
I've got it down to s science (and have since around 2007).
>
> This is an issue I've had to deal with a lot over the years and I do not
> have a simple solution. You also suggested Eric to use "My Library" and
> that is not going in the FAQ.
Who said it should; however, it seems idiotic to link to PrototypeJS and
not My Library.
>
>>> Nor am I hopeless. Annoyed, yes, a little annoyed.
>>
>> Join the club. Starting with isHostMethod, then viewport measurement
>> and now this (and many in between). I'm tired of revisiting the same
>> "arguments" over and over.
>
> OK, I think I see where you're coming from. I looked at each argument
> separately, not as the same thing.
As you should have, but each time it was like you went off the course
for no good reason.
>
> I agree that there is value in having a good simple answer to the
> question. The problem is that the question can't be answered so simply.
What question?
> Reading style values is a simple thing to want to do but a general
> solution to solve for that is not going to be simple.
That's what you think. :)
Eric Bednarz
> Eric Bednarz wrote:
>> Since I never attempted to retrieve offset values of relatively
>> positioned elements by script, […]
> "Offset" values and top/left style values are different
> things.
Ah.
> Offset", to me, is about the badly defined and highly
> inconsistent "offsetTop", "offsetLeft", and "offsetParent".
“Offset”, to CSS 2.1, is about section 9.3.2.
>> <http://bednarz.nl/tmp/relative/>
(Unfortunately I had to move that:)
<http://bednarz.nl/sandbox/js/relative/>
> What I do not understand is the "expected" column. What are the
> expectations coming from?
See above; is the specification (candidate) an unreasonable point of
reference?
>> - jQuery does nothing more than returning the wrong results provided by the
>> getComputedStyle/currentStyle branch
>
> To retrieve element coordinate offsets with jQuery,
Anybody who understands the difference between relative and absolute
positioning should be able to understand why I am having a hard time to
understand this persistant fixation on wanting to get element
coordinates in respect to anything else but that element’s position in
the normal flow.
> jQuery's offset
> method would be the method for that.
I want to retrieve CSS values, and jQuery (as do some other libraries)
pretends to provide a method to do that; unsurprisingly, the cross
browser proposition is restricted to a tiny subset of the possible use
cases.
Eric Bednarz
> Here's the thing. You can make use of offsetLeft/Top to check your
> work. For instance, take your relative position quandary.
^^^^^^^^
OK.
> […] 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';
Unless I miss someting, that strategy is only useful for absolute
positioning (I like it, and I use it, in that context).
David Mark
My Library's is pretty good. The one in the new primer (see my site) is
better.
David Mark
Nope. Works like a charm for relative and fixed. Why wouldn't it?
David Mark
And it does appear you are missing (snipped?) the latter part of the
explanation. Remember when I said to check if it moved. That's the
key. Again, vive la différence! :)
David Mark
Yep. Immediately following the cited bit was this paragraph. Without
it, the above makes no sense. Did you stop reading at that point? :)
"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! ;)"
Garrett Smith
changes offsetTop and offsetLeft, respectively. That hardly seems worth
trying to prove, though.
David Mark
Jesus wept. It's a tag team of bad snipping plus following up without
reading prior posts (from _today_ no less!)
From a post earlier today decrying the odd snipping, which destroyed the
context of the above:-
"Yep. Immediately following the cited bit was this paragraph. Without
it, the above makes no sense. Did you stop reading at that point? :)
"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! ;)""
...so now I am quoting myself quoting myself. If this sort of shit
keeps up, I'll be checking out of Usenet for good. It's too irritating.
Eric Bednarz
I didn’t miss it, I didn’t think it through properly; it is obvious that
you still have to do something after the above whithout comprehensively
quoting the rest of your message[0], so please don’t blame other
people’s simplemindedness on me, it’s hard enough to be responsible for
my own.
> Remember when I said to check if it moved. That's the
> key. Again, vive la différence! :)
Multiplying the first offsetTop/Left value by 2 and substracting the
second one does indeed result in the (computed pixel-) value of the
offset property. Sometimes I’m a bit slow (posting after three in the
morning doesn’t help much :-). Thanks.
[0] cf. <http://www.cs.tut.fi/~jkorpela/usenet/laws.html#law22>
David Mark
> David Mark <dmark....@gmail.com> writes:
>
>> David Mark wrote:
>>> Eric Bednarz wrote:
>>>> David Mark <dmark....@gmail.com> writes:
>
>>>>> […] 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';
>>>> Unless I miss someting, that strategy is only useful for absolute
>>>> positioning (I like it, and I use it, in that context).
>>> Nope. Works like a charm for relative and fixed. Why wouldn't it?
>> And it does appear you are missing (snipped?) the latter part of the
>> explanation.
>
> I didn’t miss it, I didn’t think it through properly; it is obvious that
> you still have to do something after the above whithout comprehensively
> quoting the rest of your message[0], so please don’t blame other
> people’s simplemindedness on me, it’s hard enough to be responsible for
> my own.
Fair enough. :)
>
>> Remember when I said to check if it moved. That's the
>> key. Again, vive la différence! :)
>
> Multiplying the first offsetTop/Left value by 2 and substracting the
> second one does indeed result in the (computed pixel-) value of the
> offset property. Sometimes I’m a bit slow (posting after three in the
> morning doesn’t help much :-). Thanks.
NP. Glad to help!
Garrett Smith
> Garrett Smith <dhtmlk...@gmail.com> writes:
>
>> Eric Bednarz wrote:
>
>>> Since I never attempted to retrieve offset values of relatively
>>> positioned elements by script, […]
>
>> "Offset" values and top/left style values are different
>> things.
>
> Ah.
>
>> Offset", to me, is about the badly defined and highly
>> inconsistent "offsetTop", "offsetLeft", and "offsetParent".
>
> “Offset”, to CSS 2.1, is about section 9.3.2.
>
"offset" is a prefix for three nasty properties and one good property.
The nasties are: offsetLeft, offsetTop, and offsetParent. The one good
one is offsetWidth.
Those are defined in CSSOM Views, and, depending on the version of that
document, you'll get completely different definitions for the bad ones.
The implementations of IE 6-8 are all different. Likely IE9 will be
different again. Of course other browsers all vary on what they do for
those properties as well.
If you're trying to obtain element coordinates, relative to the root,
method getBoundingClientRect (also specified in CSSOM Views) does that.
>>> <http://bednarz.nl/tmp/relative/>
>
> (Unfortunately I had to move that:)
>
> <http://bednarz.nl/sandbox/js/relative/>
>
>> What I do not understand is the "expected" column. What are the
>> expectations coming from?
>
> See above; is the specification (candidate) an unreasonable point of
> reference?
>
>>> - jQuery does nothing more than returning the wrong results provided by the
>>> getComputedStyle/currentStyle branch
>> To retrieve element coordinate offsets with jQuery,
>
> Anybody who understands the difference between relative and absolute
> positioning should be able to understand why I am having a hard time to
> understand this persistant fixation on wanting to get element
> coordinates in respect to anything else but that element’s position in
> the normal flow.
>
It is unclear when you write "position" what you mean. Do you mean "top"
and "left" values or is it something else?
>> jQuery's offset
>> method would be the method for that.
>
> I want to retrieve CSS values, and jQuery (as do some other libraries)
> pretends to provide a method to do that; unsurprisingly, the cross
> browser proposition is restricted to a tiny subset of the possible use
> cases.
Use getComputedStyle for ViewCSS and currentStyle for IE to get that. It
is going to be limited to what the browsers can do. In some cases, you
will find browser returning "auto" or worse -- when querying "left"
value, you'll get a value that corresponds to that element's marginLeft.
To get around that issue, the stylesheet will need a left value.
The dfference of IE current style is even greater.
David Mark
> Eric Bednarz wrote:
>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>
>>> Eric Bednarz wrote:
>>
>>>> Since I never attempted to retrieve offset values of relatively
>>>> positioned elements by script, […]
>>
>>> "Offset" values and top/left style values are different
>>> things.
>>
>> Ah.
>>
>>> Offset", to me, is about the badly defined and highly
>>> inconsistent "offsetTop", "offsetLeft", and "offsetParent".
>>
>> “Offset”, to CSS 2.1, is about section 9.3.2.
>>
>
> "offset" is a prefix for three nasty properties and one good property.
> The nasties are: offsetLeft, offsetTop, and offsetParent. The one good
> one is offsetWidth.
Are you abstaining on offsetHeight? And BTW, the nasties can be very
useful if you know how to train them. See the final resolution of this
thread. ;)
>
> Those are defined in CSSOM Views, and, depending on the version of that
> document, you'll get completely different definitions for the bad ones.
They are written about in there, but that was after the fact, so
whatever is written is just trying to explain what has already happened.
It won't change reality retroactively and it remains to be seen if that
_draft_ will ever be finished and formally approved.
> The implementations of IE 6-8 are all different.
Which doesn't matter a whit for the case at hand.
> Likely IE9 will be
> different again.
And that won't matter either. Basic math is unassailable.
> Of course other browsers all vary on what they do for
> those properties as well.
Not that much. In many contexts, the results are quite predictable
(even when not using equations that factor out the discrepancies). I've
managed to do some truly useful things with these properties over the
years, but all you seem to do is complain about them and cite daffy W3C
drafts.
>
> If you're trying to obtain element coordinates, relative to the root,
> method getBoundingClientRect (also specified in CSSOM Views) does that.
Fairly well. Of course obtaining such coordinates relative to the root
is ill-advised and virtually always unnecessary (consider that fact at
the design stage).
>
>>>> <http://bednarz.nl/tmp/relative/>
>>
>> (Unfortunately I had to move that:)
>>
>> <http://bednarz.nl/sandbox/js/relative/>
>>
>>> What I do not understand is the "expected" column. What are the
>>> expectations coming from?
>>
>> See above; is the specification (candidate) an unreasonable point of
>> reference?
>>
>>>> - jQuery does nothing more than returning the wrong results provided
>>>> by the
>>>> getComputedStyle/currentStyle branch
>>> To retrieve element coordinate offsets with jQuery,
>>
>> Anybody who understands the difference between relative and absolute
>> positioning should be able to understand why I am having a hard time to
>> understand this persistant fixation on wanting to get element
>> coordinates in respect to anything else but that element’s position in
>> the normal flow.
>>
>
> It is unclear when you write "position" what you mean. Do you mean "top"
> and "left" values or is it something else?
I believe he wants one from each of top/bottom and left/right.
>
>>> jQuery's offset
>>> method would be the method for that.
>>
>> I want to retrieve CSS values, and jQuery (as do some other libraries)
>> pretends to provide a method to do that; unsurprisingly, the cross
>> browser proposition is restricted to a tiny subset of the possible use
>> cases.
>
> Use getComputedStyle for ViewCSS and currentStyle for IE to get that.
Wrong again. (!) Do me a favor and read the thread to its conclusion
before posting any more (or just let it lie as it is done).
> It
> is going to be limited to what the browsers can do.
That's your self-imposed limitation, which seems to be the result of
blinders. :(
> In some cases, you
> will find browser returning "auto" or worse -- when querying "left"
> value, you'll get a value that corresponds to that element's marginLeft.
What a blow for you. :)
>
> To get around that issue, the stylesheet will need a left value.
Wrong.
>
> The dfference of IE current style is even greater.
Yeah, you will have to deal with non-pixel units and the aforementioned
requirement of explicitly declaring the position in a style sheet.
That's all and it is all unnecessary.
If you pursue this direction further into the weeds, I am just going to
go ballistic. It's almost like you are being deliberately loopy (and
that pisses me off as I don't care to have to clear up what you
obscure). Leave it alone. We're cone here. Thanks for your attempts
to help.
Garrett Smith
> Garrett Smith wrote:
>> Eric Bednarz wrote:
>>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>>
>>>> Eric Bednarz wrote:
>>>>> Since I never attempted to retrieve offset values of relatively
>>>>> positioned elements by script, […]
>>>> "Offset" values and top/left style values are different
>>>> things.
>>> Ah.
>>>
>>>> Offset", to me, is about the badly defined and highly
>>>> inconsistent "offsetTop", "offsetLeft", and "offsetParent".
>>> “Offset”, to CSS 2.1, is about section 9.3.2.
>>>
>> "offset" is a prefix for three nasty properties and one good property.
>> The nasties are: offsetLeft, offsetTop, and offsetParent. The one good
>> one is offsetWidth.
>
> Are you abstaining on offsetHeight? And BTW, the nasties can be very
> useful if you know how to train them. See the final resolution of this
> thread. ;)
>
Looking down further...
>> Those are defined in CSSOM Views, and, depending on the version of that
>> document, you'll get completely different definitions for the bad ones.
>
> They are written about in there, but that was after the fact, so
> whatever is written is just trying to explain what has already happened.
> It won't change reality retroactively and it remains to be seen if that
> _draft_ will ever be finished and formally approved.
>
>> The implementations of IE 6-8 are all different.
>
> Which doesn't matter a whit for the case at hand.
>
>> Likely IE9 will be
>> different again.
>
> And that won't matter either. Basic math is unassailable.
>
Is it here?
Interesting.
I would probably rather figure out if that is correct, and why, before
claiming a final resolution.
[...]
> If you pursue this direction further into the weeds, I am just going to
> go ballistic. It's almost like you are being deliberately loopy (and
> that pisses me off as I don't care to have to clear up what you
> obscure). Leave it alone. We're cone here. Thanks for your attempts
> to help.
I am trying to get to the heart of the problem.
Making threats to "go ballistic" is childish. And I don't think you'd
get very far with that if we met in person :-D.
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> Eric Bednarz wrote:
>>>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>>>
>>>>> Eric Bednarz wrote:
>>>>>> Since I never attempted to retrieve offset values of relatively
>>>>>> positioned elements by script, […]
>>>>> "Offset" values and top/left style values are different
>>>>> things.
>>>> Ah.
>>>>
>>>>> Offset", to me, is about the badly defined and highly
>>>>> inconsistent "offsetTop", "offsetLeft", and "offsetParent".
>>>> “Offset”, to CSS 2.1, is about section 9.3.2.
>>>>
>>> "offset" is a prefix for three nasty properties and one good property.
>>> The nasties are: offsetLeft, offsetTop, and offsetParent. The one good
>>> one is offsetWidth.
>>
>> Are you abstaining on offsetHeight? And BTW, the nasties can be very
>> useful if you know how to train them. See the final resolution of this
>> thread. ;)
>>
>
> Looking down further...
Did you spot anything?
>
>>> Those are defined in CSSOM Views, and, depending on the version of that
>>> document, you'll get completely different definitions for the bad ones.
>>
>> They are written about in there, but that was after the fact, so
>> whatever is written is just trying to explain what has already happened.
>> It won't change reality retroactively and it remains to be seen if that
>> _draft_ will ever be finished and formally approved.
>>
>>> The implementations of IE 6-8 are all different.
>>
>> Which doesn't matter a whit for the case at hand.
>>
>>> Likely IE9 will be
>>> different again.
>>
>> And that won't matter either. Basic math is unassailable.
>>
>
> Is it here?
No question. Seriously, read the thread from start to finish (and
perhaps the last one we had on this topic) and then go look at the
answers on my site (position primer) if you can't spot the pattern.
Not really. One from each is how you position an element (without
affecting its size). See Eric's original test page as it would seem the
best indicator of what he's trying to do.
>
> I would probably rather figure out if that is correct, and why, before
> claiming a final resolution.
He "claimed" the final resolution. Did you finish reading the thread or
not? This is getting ridiculous.
>
> [...]
>
>> If you pursue this direction further into the weeds, I am just going to
>> go ballistic. It's almost like you are being deliberately loopy (and
>> that pisses me off as I don't care to have to clear up what you
>> obscure). Leave it alone. We're cone here. Thanks for your attempts
>> to help.
>
> I am trying to get to the heart of the problem.
So far, you _are_ the problem.
>
> Making threats to "go ballistic" is childish. And I don't think you'd
> get very far with that if we met in person :-D.
Talk about childish. Gee, what would you do mister body-builder? Give
me a fucking break.
Garrett Smith
> Garrett Smith wrote:
>> David Mark wrote:
>>> Garrett Smith wrote:
>>>> Eric Bednarz wrote:
>>>>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>>>>
>>>>>> Eric Bednarz wrote:
>> I am trying to get to the heart of the problem.
>
> So far, you _are_ the problem.
>
No, the problem is related to getting computed/current style. Before
jumping to conclusions on the final answer, the problem description
needs more detail.
The detail needed is: (1)what specifically is wanted and (2)why/what
situation (what is the OP trying to do).
We also need clarification on terminology for "offset".
>> Making threats to "go ballistic" is childish. And I don't think you'd
>> get very far with that if we met in person :-D.
>
> Talk about childish. Gee, what would you do mister body-builder? Give
> me a fucking break.
"Going ballistic" has nothing to do with technical discussion. It is
personal, irrelevant noise. Just like your "final solution" is more
about your ego than the OP's actual problem.
"Argument From Intimidation" doesn't have any place in a technical
discussion (of programming).
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> Eric Bednarz wrote:
>>>>>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>>>>>
>>>>>>> Eric Bednarz wrote:
> [...]
>
>>> I am trying to get to the heart of the problem.
>>
>> So far, you _are_ the problem.
>>
> No, the problem is related to getting computed/current style. Before
> jumping to conclusions on the final answer, the problem description
> needs more detail.
>
> The detail needed is: (1)what specifically is wanted and (2)why/what
> situation (what is the OP trying to do).
>
> We also need clarification on terminology for "offset".
>
>>> Making threats to "go ballistic" is childish. And I don't think you'd
>>> get very far with that if we met in person :-D.
>>
>> Talk about childish. Gee, what would you do mister body-builder? Give
>> me a fucking break.
> "Going ballistic" has nothing to do with technical discussion.
So?
> It is
> personal, irrelevant noise.
So are you. :)
> Just like your "final solution" is more
> about your ego than the OP's actual problem.
Don't be a loser. The OP seemed to like it, as have numerous others who
have read the position primer on my site. This is all about your
rapidly deflating ego. ;)
>
> "Argument From Intimidation" doesn't have any place in a technical
> discussion (of programming).
Oh shut up before I plonk you. :) You really are on my last nerve.