Re: getComputedStyle, where is my LI?

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/

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

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.

Imagining? Have you been reading any of this?

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.

Oh brother. So you didn't bring up some BODY related quirk when we
were talking about a positioned LI? Not to mention TD's.

The unreliable offsetTop was suggested by you.

You just keep repeating the same thing. I told you from the start
that it wasn't meant to be a substitution for getComputedStyle (see
apples vs. oranges). Of course, they work very well together when it
comes to feature testing quirks like the one that was giving you
trouble.

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 related to your expedition into the weeds related to the BODY
element.

All the while you refusing to
read what I wrote, not reading the spec, etc.

Don't be ridiculous. You started quoted all sorts of unrelated junk
verbatim. Don't bother doing that.

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

We've long since established that, as well as more than one solution.

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.

And what problem did I imagine that did not exist? Near as I can
tell, every problem discussed so far has been your own.

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.

Again with the BODY quirks. This isn't a contest between
getComputedStyle and the offset* properties. And, as mentioned three
times, you can test for these issues by using the two together.

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 made no explanation of 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.

Yes, obviously you can avoid the problem entirely. What does that
have to do with the rest of this time-wasting.

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

No telling what you are talking about at this point.

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.

You said enough (when you finally got around to it).

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

Again. I didn't tell you to substitute offsetTop for
getComputedStyle.

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

I already did the VK comparison bit.

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.

Of course, I was referring to the "critique" that I quoted above. And
no, this thread did not belong in a CSS group.