getComputedStyle, where is my LI?

David Mark wrote:

On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]

follow up to comp.infosystems.www.authoring.stylesheets

(this is more of a CSS topic).

It certainly is not.

The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?

I have already linked them in this thread, and they appear below.

If you wanted to - for example - move the list
item down two pixels, you would add two to whatever is there. In the
case of "auto" you would assume 0. GIGO.
Is the answer to the question: How can I position an element. Who asked?
I would not assume "0" for auto, because I read the specification
(indeed I cited it on this very thread) and I understand that such
assumption would be incorrect. "auto" is not 0.
Doesn't matter. I wouldn't bother memorizing such useless trivia as
"auto" is not a computed style at all. If you run into walls like
this, change direction.
No need to memorize, the specification is publicly available. I linked
to it earlier in this thread.

Has nothing to do with the specification. It has everything to do
with memorizing quirks that are better avoided in the first place.
The issue of unexpected computed left/top/height/width was dealt with
in my library. Though it used a feature test, you really don't need
one for this. If you want to know whether a computed left/top is
accurate (meaning the element won't move if you assign that style),
check whether offsetLeft/Top change. Same goes for dimensions (use
offsetHeight/Width to check that work).

It is too complicated to memorize. Things that make sense conceptually
(patterns or formulas) seem easier memorize.

Anyone may read it.

Are you channeling VK now?

I am not channeling VK.

I am explaining where to find the expected outcome of getComputedStyle.

If instead you are interested in the offset position, use offsetLeft/
Top, preferably within the confines of a positioned parent element.
OffsetLeft and offsetTop are not standard. That approach works for UL,
but not other elements, such as TD (I recall problems with Safari 2).
Works great within a positioned parent. Doesn't matter if they are
real standards (yet). If you try to measure all the way to the root
of the document, you are going to end up with a lot of code.
How about Safari 2, inside a TD?

How about what? If you think you have a problem with that browser and
that element, spell it out.

A style top value is not even close to the same thing as offsetTop.

OffsetTop would, according to you, return distance positioned-child ->
positioned-parent.

That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.

What was wanted was to know the |top| position of the LI.

Even if offsetTop were wanted, it doesn't always behave as you claim it
does.

Above, see where I wrote:

That approach works for UL, but not other elements, such as TD (I
recall problems with Safari 2)

It is not Safari 2. IT is all versions of Safari and Chrome, too.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.

Some older implementations calculated offsetLeft from parentNode
border edge. This was, for over 1 year, required by CSSOM Views.

OffsetTop does not return CSS Pixles. It returns a rounded number.

Regardless, the offsetTop includes margin or other things that affect
in-flow offset. That is quite a bit different from a computed style for

top|.

Nonstandard properties are problematic because they often get copied in
ways that are different from the original.

You just don't get it. It has nothing to do with standard vs. non-
standard. These are apples and oranges. There is correlation, which
is why you can use one to check the other, but they are not the same
thing. Furthermore, one is known to be accurate (in a usable subset
anyway) and one is known to be all over the map.

What I do get is my intention of this thread. What was that? Oh,
discussing how and why getComputedStyle is a problem.

I also know the pertinent specification and how to read it.

I also get that offsetTop is not an alternative to reading
getComputedStyle top.

I also get some familiar arrogance from you (which reminds me why I
ignored your posts for such a long time).

This NG is an appropriate place to discuss what browsers do, post test
code, link to the pertinent specifications.

I get it.

The result is a sort of
"mystery meat" property which may mean any things in many contexts.

We've been over this a million times. Design for the cases that are
known to work cross-browser.

OffsetTop is the poster child for mystery meat properties.

Seems you always focus on the wrong issue. There's nothing better
available for determining the position of an element. Certainly not
computed styles.

Offset top is probably the least interoperable property of all.

I really can't think of a property so widely implemented, with as much
deviation and diversity as offsetTop.

Try your advice in a TD in Safari, for example.

I explained that problem to VK recently.

I don't care what you explained to VK.

Some of what I wrote to VK is conceptually pertinent to this discussion.

e.g. "Read the specification." and

What you call "Psuedo-philosophic twisted definitions" I call the
ECMAScript specification.

Oddly, what Opera returns for the computed style string + "px" for the
value that you have described as "the offset position from the
positioned parent element."
Again, who cares what they say (or do?) The computed left/top of a
relatively positioned element is not something you should rely on.
That's always been the case, driven home by Opera more than once.
Generally standards approach should be favored over proprietary,
nonstandard properties.

And in this case, not. Obviously.

The computed style is standard and specified. The value "auto" is a
standard and specified value for computed style for top.

It is certainly not a computed style. It never is and it should be
obvious why not.

No, that is plainly false.

The pertinent specifications are DOM 2 StyleSheets and CSS 2/CSS 2.1.
DOM 2 StyleSheets makes reference to CSS 2.

That is clearly stated in the link to CSS2 spec that I provided earlier.http://www.w3.org/TR/CSS2/visuren.html#position-props

| Computed value: for 'position:relative', see section Relative
| Positioning. For 'position:static', 'auto'. Otherwise: if specified as
| a length, the corresponding absolute length; if specified as a
| percentage, the specified value; otherwise, 'auto'.

So for "position: static", the expected computed value is "auto".

You are latching onto pedantic nonsense again. A statically
positioned element doesn't move when you adjust left and top, so
computing those styles is impossible.

What you call "pedantic nonsense", I call the CSS 2.1 specification.

The specification and API for reading element styles is overly
complicated and not interoperable. Indeed the specification has changed
definitions for what "computed style" is between 2 and 2.1.

Method getComputedStyle should indeed return that value, as stated in
DOM 2 StyleSheets[1]:http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed

It would be a really silly design that would ask for it.

A script would not want auto, in most cases.

In most cases, the script wants what is called an "absolute value".

| 2.2.1. Override and computed style sheet
|
| Interface ViewCSS (introduced in DOM Level 2)
|
| This interface represents a CSS view. The getComputedStyle method
| provides a read only access to the _computed values_ of an element.

Why are you quoting this?

To clearly determine the expected outcome of "getComputedStyle".

You wrote:

"auto" is not a computed style at all.

And then reaffirmed:

It is certainly not a computed style. It never is and it should be
obvious why not.

That is wrong. You've not cited any reference for why you believe this
to be true.

I have cited the specification (three times or so) which clearly
explains that that is wrong.

What does getComputedStyle really do?

We could either:
a) take your word for it
b) read the pertinent specification.

How about lets look at the pertinent specification?

DOM 2 CSS, as I quoted above.

That leads to the definition of "computed values". That definition
varies between CSS2 and CSS2.1:
CSS2:http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value

What leads to it?

DOM 2 StyleSheets, for interface ViewCSS links to _computed_values_.
That link is to CSS 2. (I believe that it should be to CSS 2.1 instead).

CSS2:

| Specified values may be absolute (i.e., they are not specified
| relative to another value, as in 'red' or '2mm') or relative (i.e.,
| they are specified relative to another value, as in 'auto', '2em', and
| '12%'). For absolute values, no computation is needed to find the
| computed value.
|
| Relative values, on the other hand, must be transformed into computed
| values: percentages must be multiplied by a reference value (each
| property defines which value that is), values with relative units (em,
| ex, px) must be made absolute by multiplying with the appropriate font
| or pixel size, 'auto' values must be computed by the formulas given
| with each property, certain keywords ('smaller', 'bolder', 'inherit')
| must be replaced according to their definitions.

CSS2.1http://www.w3.org/TR/CSS21/cascade.html#computed-value

| When the specified value is not 'inherit', the computed value of a
| property is determined as specified by the Computed Value line in the
| definition of the property.

The definition for Computed Value, for |top|, one more time:

Why are you repeating yourself in the same post?

I have repeated the pertinent part of the specification to clarify that
"auto" is, indeed, a computed value.

There may be others who missed the explanation, or refused to read the
relevant specifications (or for inexplicable reasons, take your word
that "auto" is not a computed style).

[snip]

In many browsers, getComputedStyle returns used values for some
properties. The used value and the computed value are not the same
thing.http://www.w3.org/TR/CSS2/cascade.html#used-value

No kidding. The implementations of getComputedStyle are all over the
map. That's why you should stick to what is known to work and use
better alternatives where they exist. Add in that there is no such
method in IE and you've got a clear loser.

A better alternative is needed. offsetTop is certainly not that.
OffsetTop is for "top" only. Not margin, etc. It is not comprehensive.
It is not interoperable, either.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 2, 4:18*pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:

David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]

follow up to comp.infosystems.www.authoring.stylesheets

(this is more of a CSS topic).

It certainly is not.

The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?

Of course not. I've seen them before. But thanks.

I have already linked them in this thread, and they appear below.

Again?

If you wanted to - for example - move the list
item down two pixels, you would add two to whatever is there. *Inthe
case of "auto" you would assume 0. *GIGO.
Is the answer to the question: How can I position an element. Who asked?
I would not assume "0" for auto, because I read the specification
(indeed I cited it on this very thread) and I understand that such
assumption would be incorrect. "auto" is not 0.
Doesn't matter. *I wouldn't bother memorizing such useless trivia as
"auto" is not a computed style at all. *If you run into walls like
this, change direction.
No need to memorize, the specification is publicly available. I linked
to it earlier in this thread.

Has nothing to do with the specification. *It has everything to do
with memorizing quirks that are better avoided in the first place.
The issue of unexpected computed left/top/height/width was dealt with
in my library. *Though it used a feature test, you really don't need
one for this. *If you want to know whether a computed left/top is
accurate (meaning the element won't move if you assign that style),
check whether offsetLeft/Top change. *Same goes for dimensions (use
offsetHeight/Width to check that work).

It is too complicated to memorize. Things that make sense conceptually
(patterns or formulas) seem easier memorize.

Anyone may read it.

Are you channeling VK now?

I am not channeling VK.

I am explaining where to find the expected outcome of getComputedStyle.

Your expected outcome is irrelevant.

If instead you are interested in the offset position, use offsetLeft/
Top, preferably within the confines of a positioned parent element.
OffsetLeft and offsetTop are not standard. That approach works for UL,
but not other elements, such as TD (I recall problems with Safari 2)..
Works great within a positioned parent. *Doesn't matter if they are
real standards (yet). *If you try to measure all the way to the root
of the document, you are going to end up with a lot of code.
How about Safari 2, inside a TD?

How about what? *If you think you have a problem with that browser and
that element, spell it out.

A style top value is not even close to the same thing as offsetTop.

That's what *I* said.

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.

According to me? Aren't we all familiar with what those properties
do, where they fall short, etc.

That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.

I didn't suggest that as a solution to your "problem", but as an
alternative design. I also told you how to find the computed top
without worries (check your work with offsetTop). This is nowhere
near as complicated as you make it sound.

What was wanted was to know the |top| position of the LI.

A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).

Even if offsetTop were wanted, it doesn't always behave as you claim it
does.

What is this claim stuff? Have we not discussed that property a
million times in here?

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)

You keep repeating yourself.

It is not Safari 2. IT is all versions of Safari and Chrome, too.

What is?

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.

Fails in what way? I never had problems with Safari and offsetTop/
Left with regard to children of the body. Likely one of the dozen or
so feature tests takes care of it. I'll bet there's no problem with a
positioned body. And if it isn't a positioned body, I would use
getBoundingClientRect in IE.

Some older implementations calculated offsetLeft from parentNode
border edge. This was, for over 1 year, required by CSSOM Views.

All ancient history. See My Library for the solution to that (and
your other problem).

OffsetTop does not return CSS Pixles. It returns a rounded number.

No kidding. That's all you need in most cases. But since you haven't
stated what you are trying to do (other than read a property), it's
hard to give you direction.

Regardless, the offsetTop includes margin or other things that affect
in-flow offset. That is quite a bit different from a computed style for
|top|.

Didn't I mention apples and oranges at the start?

[snip]

David Mark wrote:

On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?

Of course not. I've seen them before. But thanks.

That explains it.

[...]

I am explaining where to find the expected outcome of getComputedStyle.

Your expected outcome is irrelevant.

The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.

[snip]

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.

According to me? Aren't we all familiar with what those properties
do, where they fall short, etc.

Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.

And you've forgotten a case with BODY, I see below.

That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.

I didn't suggest that as a solution to your "problem", but as an
alternative design. I also told you how to find the computed top
without worries (check your work with offsetTop). This is nowhere
near as complicated as you make it sound.

What was wanted was to know the |top| position of the LI.

A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).

Even if offsetTop were wanted, it doesn't always behave as you claim it
does.

What is this claim stuff? Have we not discussed that property a
million times in here?

The claim? You wrote:
If instead you are interested in the offset position, use offsetLeft/
Top, preferably within the confines of a positioned parent element.

That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?

It is mostly what happens, but not a general truth.

When is it not true? Well, for example:

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)

You keep repeating yourself.

You asked me to state my claim. I restated what you seemed to have not
read.

It is not Safari 2. IT is all versions of Safari and Chrome, too.

What is?

The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.

Adding an extra div with position: relative would work there.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.

Fails in what way? I never had problems with Safari and offsetTop/
Left with regard to children of the body. Likely one of the dozen or
so feature tests takes care of it. I'll bet there's no problem with a
positioned body. And if it isn't a positioned body, I would use
getBoundingClientRect in IE.

offsetTop for an element, when parent is BODY is defined in CSSOM Views.
<URL: http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop >

#2 If the offsetParent of A is null or the HTML body element return
the y-coordinate of the top border edge of A and stop this algorithm.

The "y-coordinate" being the distance from the element to the viewport.

That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.

getBoundingClientRect, where available (in the big 5 modern browsers),
has much less divergence. Much more reliable.

Pity Opera Mini returns *device* pixels, not CSS Pixels.

OffsetTop does not return CSS Pixles. It returns a rounded number.

No kidding. That's all you need in most cases. But since you haven't
stated what you are trying to do (other than read a property), it's
hard to give you direction.

I am trying to read a style value of an element.

There is reason for the code's existence.

Introducing that context takes a bit more explaining.

I could use some review on that bit of code.

I'm working on something in that file at the moment (proxy dragging).
I'll post up when I've got that done.

Regardless, the offsetTop includes margin or other things that affect
in-flow offset. That is quite a bit different from a computed style for
|top|.

Didn't I mention apples and oranges at the start?
Where?

--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 2, 6:06*pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:

David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?

Of course not. *I've seen them before. *But thanks.

That explains it.

[...]



I am explaining where to find the expected outcome of getComputedStyle..

Your expected outcome is irrelevant.

The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.

[snip]

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.

According to me? *Aren't we all familiar with what those properties
do, where they fall short, etc.

Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.

Too bad.

And you've forgotten a case with BODY, I see below.



That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.

I didn't suggest that as a solution to your "problem", but as an
alternative design. *I also told you how to find the computed top
without worries (check your work with offsetTop). *This is nowhere
near as complicated as you make it sound.

What was wanted was to know the |top| position of the LI.

A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).

Even if offsetTop were wanted, it doesn't always behave as you claim it
does.

What is this claim stuff? *Have we not discussed that property a
million times in here?

The claim? You wrote:

| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element.

And you know exactly what that means.

That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?

It is mostly what happens, but not a general truth.

Isn't that what I said?

When is it not true? Well, for example:

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)

You keep repeating yourself.

You asked me to state my claim. I restated what you seemed to have not
read.

It is not Safari 2. IT is all versions of Safari and Chrome, too.

What is?

The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.

Who cares? I'm not at all surprised that I never tripped over that
one.

Adding an extra div with position: relative would work there.

Great. Beats trying to deal with computed top styles.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.

Fails in what way? *I never had problems with Safari and offsetTop/
Left with regard to children of the body. *Likely one of the dozen or
so feature tests takes care of it. *I'll bet there's no problem with a
positioned body. *And if it isn't a positioned body, I would use
getBoundingClientRect in IE.

offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| *the y-coordinate of the top border edge of A and stop this algorithm..

The "y-coordinate" being the distance from the element to the viewport.

That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.

As mentioned, you should use these within the friendly confines of a
positioned parent. If you are measuring all the way back to the body
(and the body is not positioned), you are making a mistake.

getBoundingClientRect, where available (in the big 5 modern browsers),
has much less divergence. Much more reliable.

And so, that's what you use for children of the body.

Pity Opera Mini returns *device* pixels, not CSS Pixels.

Yes, that's a shame; but I can't remember the last time I designed
anything that relied on gBCR.

OffsetTop does not return CSS Pixles. It returns a rounded number.

No kidding. *That's all you need in most cases. *But since you haven't
stated what you are trying to do (other than read a property), it's
hard to give you direction.

I am trying to read a style value of an element.

There is reason for the code's existence.

Introducing that context takes a bit more explaining.

I could use some review on that bit of code.

I told you what to do. Save offsetTop. Retrieve the "computed" CSS
value, which may or may not fit your definition of computed, and then
set the inline style to that value. Now, did offsetTop change? If
not, great. If so, you know what the difference is.

I'm working on something in that file at the moment (proxy dragging).
I'll post up when I've got that done.

Why didn't you say so? See above for the solution (and realize this
is roughly the third time I've said it in this thread).

Regardless, the offsetTop includes margin or other things that affect
in-flow offset. That is quite a bit different from a computed style for
|top|.

Didn't I mention apples and oranges at the start?

Where?

Do you think I have time for this nonsense? Ctrl+F should find it for
you. I'm sure you quoted it at some point as well.

David Mark wrote:

On Nov 2, 6:06 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?
Of course not. I've seen them before. But thanks.
That explains it.

[...]



I am explaining where to find the expected outcome of getComputedStyle.
Your expected outcome is irrelevant.
The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.

[snip]

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.
According to me? Aren't we all familiar with what those properties
do, where they fall short, etc.
Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.

Too bad.

And you've forgotten a case with BODY, I see below.



That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.
I didn't suggest that as a solution to your "problem", but as an
alternative design. I also told you how to find the computed top
without worries (check your work with offsetTop). This is nowhere
near as complicated as you make it sound.
What was wanted was to know the |top| position of the LI.
A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).
Even if offsetTop were wanted, it doesn't always behave as you claim it
does.
What is this claim stuff? Have we not discussed that property a
million times in here?
The claim? You wrote:

| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element.

And you know exactly what that means.

That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?

It is mostly what happens, but not a general truth.

Isn't that what I said?

When is it not true? Well, for example:

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)
You keep repeating yourself.
You asked me to state my claim. I restated what you seemed to have not
read.

It is not Safari 2. IT is all versions of Safari and Chrome, too.
What is?
The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.

Who cares? I'm not at all surprised that I never tripped over that
one.

Good question. What is the point in worrying about nonstandard,

non-interoperable properties such as offsetTop?

Code for older browsers, where getBoundingClientRect is unavailable,
would probably have to care about that.

Adding an extra div with position: relative would work there.

Great. Beats trying to deal with computed top styles.

Ah, but that does not address the issue of BODY.

positioned_child -> parent_body.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.
Fails in what way? I never had problems with Safari and offsetTop/
Left with regard to children of the body. Likely one of the dozen or
so feature tests takes care of it. I'll bet there's no problem with a
positioned body. And if it isn't a positioned body, I would use
getBoundingClientRect in IE.
offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| the y-coordinate of the top border edge of A and stop this algorithm.

The "y-coordinate" being the distance from the element to the viewport.

That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.

As mentioned, you should use these within the friendly confines of a
positioned parent. If you are measuring all the way back to the body
(and the body is not positioned), you are making a mistake.

The body may be the element's parent node "all the way back".

The body being positioned is irrelevant in CSSOM Views. I just explained
that, cited the specification, linked to it. Was I not clear enough?

That is what changed from IE7 -> IE8. IE8 implements a draft that
changes what offsetTop was in IE7.

I don't see where you are going with the premise of "the body is not
positioned" being part of a mistake.

Giving position: relative on body does not change anything. It just
different interoperability quirks, depending on the browser and how one
defines "quirk" (the editors draft is arguably quirky in that it
deviates from what IE did in a way that requires special case handling
for BODY).
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 2, 9:01*pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:

David Mark wrote:
On Nov 2, 6:06 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| inDOM
2 StyleSheets?
Of course not. *I've seen them before. *But thanks.
That explains it.

[...]

I am explaining where to find the expected outcome of getComputedStyle.
Your expected outcome is irrelevant.
The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.

[snip]

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.
According to me? *Aren't we all familiar with what those properties
do, where they fall short, etc.
Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.

Too bad.

And you've forgotten a case with BODY, I see below.

That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.
I didn't suggest that as a solution to your "problem", but as an
alternative design. *I also told you how to find the computed top
without worries (check your work with offsetTop). *This is nowhere
near as complicated as you make it sound.
What was wanted was to know the |top| position of the LI.
A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).
Even if offsetTop were wanted, it doesn't always behave as you claimit
does.
What is this claim stuff? *Have we not discussed that property a
million times in here?
The claim? You wrote:

| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element.

And you know exactly what that means.

That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?

It is mostly what happens, but not a general truth.

Isn't that what I said?

When is it not true? Well, for example:

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)
You keep repeating yourself.
You asked me to state my claim. I restated what you seemed to have not
read.

It is not Safari 2. IT is all versions of Safari and Chrome, too.
What is?
The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.

Who cares? *I'm not at all surprised that I never tripped over that
one.

Good question. What is the point in worrying about nonstandard,
non-interoperable properties such as offsetTop?

Code for older browsers, where getBoundingClientRect is unavailable,
would probably have to care about that.

Adding an extra div with position: relative would work there.

Great. *Beats trying to deal with computed top styles.

Ah, but that does not address the issue of BODY.

positioned_child -> parent_body.



offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.
Fails in what way? *I never had problems with Safari and offsetTop/
Left with regard to children of the body. *Likely one of the dozen or
so feature tests takes care of it. *I'll bet there's no problem with a
positioned body. *And if it isn't a positioned body, I would use
getBoundingClientRect in IE.
offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| *the y-coordinate of the top border edge of A and stop this algorithm.

The "y-coordinate" being the distance from the element to the viewport..

That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.

As mentioned, you should use these within the friendly confines of a
positioned parent. *If you are measuring all the way back to the body
(and the body is not positioned), you are making a mistake.

The body may be the element's parent node "all the way back".

Not in the case of your problem.

The body being positioned is irrelevant in CSSOM Views. I just explained
that, cited the specification, linked to it. Was I not clear enough?

You are rarely clear and this thread is no exception.

That is what changed from IE7 -> IE8. IE8 implements a draft that
changes what offsetTop was in IE7.

Great. And what does that have to do with the problem at hand?

I don't see where you are going with the premise of "the body is not
positioned" being part of a mistake.

Meaning you shouldn't be measuring the distance from the body's origin
to the HTML element's origin. If you are, you are making a mistake.
We've been over this a thousand times.

Giving position: relative on body does not change anything. It just
different interoperability quirks, depending on the browser and how one
defines "quirk" (the editors draft is arguably quirky in that it
deviates from what IE did in a way that requires special case handling
for BODY).

It changes exactly what I explained it does and is a much better
proposition than dealing with a static body (where you must measure to
the HTML origin).

I really think you are worrying about nothing. And I take it you
finally got the message about how to solve your current problem. If
you want further advice (e.g. IE8 and the body element), you'll need
to post an example.

On Nov 2, 6:06*pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:

David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?

Of course not. *I've seen them before. *But thanks.

That explains it.

[...]



I am explaining where to find the expected outcome of getComputedStyle..

Your expected outcome is irrelevant.

The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.

[snip]

OffsetTop would, according to you, return distance positioned-child -
positioned-parent.

According to me? *Aren't we all familiar with what those properties
do, where they fall short, etc.

Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.

And you've forgotten a case with BODY, I see below.



That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.

I didn't suggest that as a solution to your "problem", but as an
alternative design. *I also told you how to find the computed top
without worries (check your work with offsetTop). *This is nowhere
near as complicated as you make it sound.

What was wanted was to know the |top| position of the LI.

A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).

Even if offsetTop were wanted, it doesn't always behave as you claim it
does.

What is this claim stuff? *Have we not discussed that property a
million times in here?

The claim? You wrote:

| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element.

That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?

It is mostly what happens, but not a general truth.

When is it not true? Well, for example:

Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)

You keep repeating yourself.

You asked me to state my claim. I restated what you seemed to have not
read.

It is not Safari 2. IT is all versions of Safari and Chrome, too.

What is?

The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.

Adding an extra div with position: relative would work there.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.

Fails in what way? *I never had problems with Safari and offsetTop/
Left with regard to children of the body. *Likely one of the dozen or
so feature tests takes care of it. *I'll bet there's no problem with a
positioned body. *And if it isn't a positioned body, I would use
getBoundingClientRect in IE.

offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| *the y-coordinate of the top border edge of A and stop this algorithm..

Maybe if you hadn't posted the phone book, I could have seen what you
were trying to get across (which is still irrelevant to the issue at
hand). If IE8 did this then shame on MS (again). Funny I never had
am issue with Safari, Chrome, etc. So, it would be prudent to
determine if offsetLeft returns what you expect (and adjust
accordingly). Use the same technique described for your other problem
(e.g. set styles, check against expected offsetLeft/Top).

David Mark wrote:

On Nov 2, 9:01 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 6:06 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?
Of course not. I've seen them before. But thanks.
That explains it.
[...]
I am explaining where to find the expected outcome of getComputedStyle.
Your expected outcome is irrelevant.
The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.
[snip]
OffsetTop would, according to you, return distance positioned-child -
positioned-parent.
According to me? Aren't we all familiar with what those properties
do, where they fall short, etc.
Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.
Too bad.
And you've forgotten a case with BODY, I see below.
That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and so the
solution you suggested, provides a numeric version of that which is not
wanted.
I didn't suggest that as a solution to your "problem", but as an
alternative design. I also told you how to find the computed top
without worries (check your work with offsetTop). This is nowhere
near as complicated as you make it sound.
What was wanted was to know the |top| position of the LI.
A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).
Even if offsetTop were wanted, it doesn't always behave as you claim it
does.
What is this claim stuff? Have we not discussed that property a
million times in here?
The claim? You wrote:
| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element.
And you know exactly what that means.
That implies that offsetTop returns the distance between the element and
its positioned parent element. Is that not what you meant to say?
It is mostly what happens, but not a general truth.
Isn't that what I said?
When is it not true? Well, for example:
Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)
You keep repeating yourself.
You asked me to state my claim. I restated what you seemed to have not
read.
It is not Safari 2. IT is all versions of Safari and Chrome, too.
What is?
The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent.
Who cares? I'm not at all surprised that I never tripped over that
one.
Good question. What is the point in worrying about nonstandard,
non-interoperable properties such as offsetTop?

Code for older browsers, where getBoundingClientRect is unavailable,
would probably have to care about that.

Adding an extra div with position: relative would work there.
Great. Beats trying to deal with computed top styles.
Ah, but that does not address the issue of BODY.

positioned_child -> parent_body.



offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.
Fails in what way? I never had problems with Safari and offsetTop/
Left with regard to children of the body. Likely one of the dozen or
so feature tests takes care of it. I'll bet there's no problem with a
positioned body. And if it isn't a positioned body, I would use
getBoundingClientRect in IE.
offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| the y-coordinate of the top border edge of A and stop this algorithm.
The "y-coordinate" being the distance from the element to the viewport.
That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.
As mentioned, you should use these within the friendly confines of a
positioned parent. If you are measuring all the way back to the body
(and the body is not positioned), you are making a mistake.
The body may be the element's parent node "all the way back".

Not in the case of your problem.

The body being positioned is irrelevant in CSSOM Views. I just explained
that, cited the specification, linked to it. Was I not clear enough?

You are rarely clear and this thread is no exception.


offsetLeft fails is when the parent is BODY. That is a change
introduced by CSSOM Views and was adopted in IE8, while the draft was
(IIRC) "Last Call" status.
offsetTop for an element, when parent is BODY is defined in CSSOM
Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
#2 If the offsetParent of A is null or the HTML body element return
the y-coordinate of the top border edge of A and stop this algorithm.

That is what I wrote. The term "y-coordinate" is not defined FWICT, but
that is a shortcoming of the CSSOM Views spec.

Looking at the previous edition of that:
http://www.w3.org/TR/2008/WD-cssom-view-20080222/#elementview-offsettop

If the offsetParent of element A is null or the HTML body element
return the distance, as number of CSS pixels, between the top border
edge of element A and the canvas origin and stop this algorithm.

I see that you interrupted my paragraph in the middle and ignored the
second half. Then blamed me for being unclear when it was your fault for
not reading in the first place.

It seems to have changed again, though, as the test indicates below that
"canvas origin" was replaced with "y-coordinate".

That is what changed from IE7 -> IE8. IE8 implements a draft that
changes what offsetTop was in IE7.

Great. And what does that have to do with the problem at hand?

This is a direct response to *your* suggestion. The suggestion was a red
herring. Irrelevant and inaccurate.

I don't see where you are going with the premise of "the body is not
positioned" being part of a mistake.

Meaning you shouldn't be measuring the distance from the body's origin
to the HTML element's origin. If you are, you are making a mistake.
We've been over this a thousand times.

This is not relevant to any of the discussion or relevant.

Start with a complete sentence that explains what body being position:
relative has to do with your argument (if you have one).

Giving position: relative on body does not change anything. It just
different interoperability quirks, depending on the browser and how one
defines "quirk" (the editors draft is arguably quirky in that it
deviates from what IE did in a way that requires special case handling
for BODY).

It changes exactly what I explained it does and is a much better
proposition than dealing with a static body (where you must measure to
the HTML origin).

If you do not want to read the manual, don't.

Please stop stating your misbeliefs (again and again, this is in the
spec, it is implemented in IE).

When the parent is BODY, and the child is [x] and the child and parent
both have position relative, the offsetTOp from child -> parent is from
child -> viewport edge.

Unless you take the IE6 and IE7 definition of offsetTop, (also IE5 Mac
and probably many others), where the offsetTop would be from [x] border
edge to body padding edge.

I really think you are worrying about nothing. And I take it you
finally got the message about how to solve your current problem. If
you want further advice (e.g. IE8 and the body element), you'll need
to post an example

I do not want your advice.

The solution to the "problem" my program addresses was solved in the
original thread.

You've missed the entire point of this. I am not asking for help to find
a position of an element.

If I were, then offsetTop, as you advised, is a very poor choice to do
that.

The repeated misinformation, again and again and again (about what
offsetTop is, about getComputedStyle), refusing to read what was posted,
all in the usual smart-assed attitude: (Me: "Did you read that?" You:
"of course not" (sic)).

You're not smart, not funny, not entertaining.

You could avoid this by either:
a) read the relevant specifications
b) not partake in the discussion
c) be polite, ask questions, read the replies

Posting misinformation repeatedly, but posting only misinformation that
is founded on what could only be explained as your imagination.

You've missed the point and drawn red herring to post your bad solutions
for problems that I did not ask for. This is totally irrational behavior.

If anyone on this list feels that I what I have said is incorrect,
please say so.

The following example shows divergent behavior in recent, major
browsers.

IE8: c3: 2, x:10
IE7, IE6: c3: 1, x:0

Firefox 3.6: c3: 1, x:0
Chrome: c3: 121, x:10
Opera: c3: 2, x:18

Safari 2.0: c3: 2, x:10
Safari 2.0.4: c3: 127, x:10
Safari 3: c3: 127, x:0
Safari 4: c3: 121, x:10

Looks like Opera gets it "right" per spec. I believed IE8 had the same
result, and Talbot's comment on the bug indicates that.

but these results indicate otherwise.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>OffsetTop of Child of BODY or TD</title>
</head>
<body style="position: relative; border: 10px solid">

<table border="2">
<div id="x" style="position: relative;">aaa</div>

<tr><td>cell one</td><td>cell two</td><td style="position:relative">
<div id="c3" style="position:relative">cell 3</div></td>
</tr>
<script type="text/javascript">
onload = function(){
var ol= document.getElementById("c3").offsetLeft,
xol= document.getElementById("x").offsetLeft,
m = document.getElementById("m");
m.firstChild.data = "c3: " + ol + ", x:" + xol;
}
</script>
<pre id="m">-</pre>
</body>
</html>

OffsetTop is not reliable. It is not worth digging up these bugs. It is
best to be aware of the bugs and instead use something more reliable.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 3, 12:40*am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:

David Mark wrote:
On Nov 2, 9:01 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 6:06 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
It certainly is not.
The method |getComputedStyle| is related to CSS 2.1. Did you read any of
the citations to the official specification of |getComputedStyle| in DOM
2 StyleSheets?
Of course not. *I've seen them before. *But thanks.
That explains it.
[...]
I am explaining where to find the expected outcome of getComputedStyle.
Your expected outcome is irrelevant.
The expected outcome of getComputedStyle can be found in the DOM 2 Style
specification.
[snip]
OffsetTop would, according to you, return distance positioned-child -
positioned-parent.
According to me? *Aren't we all familiar with what those properties
do, where they fall short, etc.
Probably not. There are ways in which it fails that I have probably
forgotten or have not ever learned. offsetTop/Left/Parent is a mess.
Too bad.
And you've forgotten a case with BODY, I see below.
That would not be the solution to finding the computed style top value
of an element. Indeed, what Opera 10.1 gives for computed style top
seems to be offsetTop + "px". This is what is *not* wanted, and sothe
solution you suggested, provides a numeric version of that which is not
wanted.
I didn't suggest that as a solution to your "problem", but as an
alternative design. *I also told you how to find the computed top
without worries (check your work with offsetTop). *This is nowhere
near as complicated as you make it sound.
What was wanted was to know the |top| position of the LI.
A perfectly useless thing to know as you know in advance you should
set it to 0 for a relatively positioned element (or use offsetTop to
verify whatever the browser sees as the default).
Even if offsetTop were wanted, it doesn't always behave as you claim it
does.
What is this claim stuff? *Have we not discussed that property a
million times in here?
The claim? You wrote:
| If instead you are interested in the offset position, use offsetLeft/
| Top, preferably within the confines of a positioned parent element..
And you know exactly what that means.
That implies that offsetTop returns the distance between the elementand
its positioned parent element. Is that not what you meant to say?
It is mostly what happens, but not a general truth.
Isn't that what I said?
When is it not true? Well, for example:
Above, see where I wrote:
| That approach works for UL, but not other elements, such as TD (I
| recall problems with Safari 2)
You keep repeating yourself.
You asked me to state my claim. I restated what you seemed to have not
read.
It is not Safari 2. IT is all versions of Safari and Chrome, too.
What is?
The problem. What problem? The problem of finding the offsetLeft of an
element inside a parent element. Doesn't work when the parent is a TD.
Assigning position: relative to the TD won't make it an offsetParent..
Who cares? *I'm not at all surprised that I never tripped over that
one.
Good question. What is the point in worrying about nonstandard,
non-interoperable properties such as offsetTop?

Code for older browsers, where getBoundingClientRect is unavailable,
would probably have to care about that.

Adding an extra div with position: relative would work there.
Great. *Beats trying to deal with computed top styles.
Ah, but that does not address the issue of BODY.

positioned_child -> parent_body.

offsetLeft fails is when the parent is BODY. That is a change introduced
by CSSOM Views and was adopted in IE8, while the draft was (IIRC) "Last
Call" status.
Fails in what way? *I never had problems with Safari and offsetTop/
Left with regard to children of the body. *Likely one of the dozen or
so feature tests takes care of it. *I'll bet there's no problem with a
positioned body. *And if it isn't a positioned body, I would use
getBoundingClientRect in IE.
offsetTop for an element, when parent is BODY is defined in CSSOM Views.
URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| *the y-coordinate of the top border edge of A and stop this algorithm.
The "y-coordinate" being the distance from the element to the viewport.
That changed how offsetTop worked from IE7 to IE8, as IE8 implemented
that editor's draft or LC.
As mentioned, you should use these within the friendly confines of a
positioned parent. *If you are measuring all the way back to the body
(and the body is not positioned), you are making a mistake.
The body may be the element's parent node "all the way back".

Not in the case of your problem.

The body being positioned is irrelevant in CSSOM Views. I just explained
that, cited the specification, linked to it. Was I not clear enough?

You are rarely clear and this thread is no exception.

| offsetLeft fails is when the parent is BODY. That is a change
| introduced by CSSOM Views and was adopted in IE8, while the draft was
| (IIRC) "Last Call" status.
| offsetTop for an element, when parent is BODY is defined in CSSOM
| Views.
| <URL:http://www.w3.org/TR/cssom-view/#dom-htmlelement-offsettop
| #2 If the offsetParent of A is null or the HTML body element return
| *the y-coordinate of the top border edge of A and stop this algorithm..

That is what I wrote. The term "y-coordinate" is not defined FWICT, but
that is a shortcoming of the CSSOM Views spec.

Looking at the previous edition of that:http://www.w3.org/TR/2008/WD-cssom-view-20080222/#elementview-offsettop

| If the offsetParent of element A is null or the HTML body element
| return the distance, as number of CSS pixels, between the top border
| edge of element A and the canvas origin and stop this algorithm.

I see that you interrupted my paragraph in the middle and ignored the
second half. Then blamed me for being unclear when it was your fault for
not reading in the first place.

I see that you never respond to the answer, but complain about the
setting.

It seems to have changed again, though, as the test indicates below that
"canvas origin" was replaced with "y-coordinate".

Great.

That is what changed from IE7 -> IE8. IE8 implements a draft that
changes what offsetTop was in IE7.

Great. *And what does that have to do with the problem at hand?

This is a direct response to *your* suggestion. The suggestion was a red
herring. Irrelevant and inaccurate.

No, you still don't seem to understand what my (original) suggestion
was (hint: had nothing to do with the body). Nor do you seem to
recognize the more general solution (posted at least three times).

I don't see where you are going with the premise of "the body is not
positioned" being part of a mistake.

Meaning you shouldn't be measuring the distance from the body's origin
to the HTML element's origin. *If you are, you are making a mistake.
We've been over this a thousand times.

This is not relevant to any of the discussion or relevant.

That's my line. You were the one going off the path to talk about
unrelated offsetTop/Left quirks.

Start with a complete sentence that explains what body being position:
relative has to do with your argument (if you have one).

Ger real. You obviously didn't read the follow up.

Giving position: relative on body does not change anything. It just
different interoperability quirks, depending on the browser and how one
defines "quirk" (the editors draft is arguably quirky in that it
deviates from what IE did in a way that requires special case handling
for BODY).

It changes exactly what I explained it does and is a much better
proposition than dealing with a static body (where you must measure to
the HTML origin).

If you do not want to read the manual, don't.

Thanks.

Please stop stating your misbeliefs (again and again, this is in the
spec, it is implemented in IE).

Please stop changing the topic, piling on drivel and ignoring
perfectly good answers.

When the parent is BODY, and the child is [x] and the child and parent
both have position relative, the offsetTOp from child -> parent is from
child -> viewport edge.

So?

Unless you take the IE6 and IE7 definition of offsetTop, (also IE5 Mac
and probably many others), where the offsetTop would be from [x] border
edge to body padding edge.

I still don't care. If you must rely on such measurements, you should
be testing them. I've always made it a habit.

I really think you are worrying about nothing. *And I take it you
finally got the message about how to solve your current problem. *If
you want further advice (e.g. IE8 and the body element), you'll need
to post an example

I do not want your advice.

Then stop asking me questions.

The solution to the "problem" my program addresses was solved in the
original thread.

What original thread?

You've missed the entire point of this. I am not asking for help to find
a position of an element.

Dear God. I know what you are trying to do and I've told you how to
do it. Re-read from the start if you missed it.

If I were, then offsetTop, as you advised, is a very poor choice to do
that.

That's not what I advised at all. I told you that was a possibility,
depending on your then unstated design. Once you got around to
explaining what you were trying to design, I gave you the advice you
needed. Apparently you have chosen to ignore it in favor of
complaining loudly.

The repeated misinformation, again and again and again (about what
offsetTop is, about getComputedStyle),

This from you? You must be joking.

refusing to read what was posted,

Again.

all in the usual smart-assed attitude: (Me: "Did you read that?" You:
"of course not" (sic)).

You can post the phone book, but you can't make me read it.

You're not smart, not funny, not entertaining.

And you're mot on topic.

[snip]

David Mark wrote:

On Nov 3, 12:40 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 9:01 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 6:06 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:18 pm, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 2, 4:11 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
David Mark wrote:
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote:
Opera 10.1 has a buggy implementation of getComputedStyle top.
[...]
[...]
follow up to comp.infosystems.www.authoring.stylesheets
[snip]

That is what changed from IE7 -> IE8. IE8 implements a draft that
changes what offsetTop was in IE7.
Great. And what does that have to do with the problem at hand?
This is a direct response to *your* suggestion. The suggestion was a red
herring. Irrelevant and inaccurate.

No, you still don't seem to understand what my (original) suggestion
was (hint: had nothing to do with the body). Nor do you seem to
recognize the more general solution (posted at least three times).

The solution to whatever problem you are imagining is probably not
something that anyone would benefit from.

I don't see where you are going with the premise of "the body is not
positioned" being part of a mistake.
Meaning you shouldn't be measuring the distance from the body's origin
to the HTML element's origin. If you are, you are making a mistake.
We've been over this a thousand times.
This is not relevant to any of the discussion or relevant.

That's my line. You were the one going off the path to talk about
unrelated offsetTop/Left quirks.

That is a lie.

The unreliable offsetTop was suggested by you.

I avoid using those because I know how unreliable they are. It took four
posts of linking to the spec and citing the spec to try and clarify how
it was a bad suggestion to use offsetTop. All the while you refusing to
read what I wrote, not reading the spec, etc.

[snip]

Giving position: relative on body does not change anything. It just
different interoperability quirks, depending on the browser and how one
defines "quirk" (the editors draft is arguably quirky in that it
deviates from what IE did in a way that requires special case handling
for BODY).
It changes exactly what I explained it does and is a much better
proposition than dealing with a static body (where you must measure to
the HTML origin).
If you do not want to read the manual, don't.

Thanks.

Please stop stating your misbeliefs (again and again, this is in the
spec, it is implemented in IE).

Please stop changing the topic, piling on drivel and ignoring
perfectly good answers.

Answer to what? What "topic"? The thread is focused on explaining that
getComputedStyle is a problem (again).

I never asked you for you advice. I do not want your advice. You advise
on things that misunderstand the problem, imagine problem that does not
exist, and the post a poor answer to the imaginary problem.

When the parent is BODY, and the child is [x] and the child and parent
both have position relative, the offsetTOp from child -> parent is from
child -> viewport edge.

So?

Although that is not always true, where it is true, it does show that

the distance between relative child and relative parent is not found by
offsetTOp.

Unless you take the IE6 and IE7 definition of offsetTop, (also IE5 Mac
and probably many others), where the offsetTop would be from [x] border
edge to body padding edge.

I still don't care. If you must rely on such measurements, you should
be testing them. I've always made it a habit.

That doesn't account for your explanation offsetTop.

I really think you are worrying about nothing. And I take it you
finally got the message about how to solve your current problem. If
you want further advice (e.g. IE8 and the body element), you'll need
to post an example
I do not want your advice.

Then stop asking me questions.

The solution to the "problem" my program addresses was solved in the
original thread.

What original thread?

Sorry. Original post.

You've missed the entire point of this. I am not asking for help to find
a position of an element.

Dear God. I know what you are trying to do and I've told you how to
do it. Re-read from the start if you missed it.

Read it. Replied. Still not relevant (as stated in the reply).

That's not what I advised at all. I told you that was a possibility,
depending on your then unstated design. Once you got around to
explaining what you were trying to design, I gave you the advice you
needed. Apparently you have chosen to ignore it in favor of
complaining loudly.

I've not explained the requirements.

The contexts that are handled by the requirements won't work with
offsetTop.

The repeated misinformation, again and again and again (about what
offsetTop is, about getComputedStyle),

This from you? You must be joking.

refusing to read what was posted,

Again.

all in the usual smart-assed attitude: (Me: "Did you read that?" You:
"of course not" (sic)).

You can post the phone book, but you can't make me read it.

Phone book? Reminds of VK's unwillingness to read the "Books of Ecma".

You're not smart, not funny, not entertaining.

And you're mot on topic.

My post was on-topic material for both of these NGs. Indeed the original
thread was, as was all that I've written in this thread.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/