event.clientX in Safari is not like in other browsers

[Peter Michaux]

Hi,

I just did a bunch of testing and was surprised with the results. If
anyone doesn't know this stuff here is what I found about
event.clientX.

The event.clientX property in Safari is in page coordinates. In IE,
Opera, Firefox event.clientX it is in window coordinates.

This means a lot when trying to determine event location in page
coordinates. It seems best to use the old event.pageX property first if
it is a number. This works in Safari. This is how the quirksmode org
and Yahoo! UI scripts work anyway but not Flanagan's fifth edtion.

If the browser doesn't have event.pageX or it isn't a number then
hopefully we can assume that if event.clientX exists and is a number
that clientX is in window coordinates. Then add the amount of page
scroll to the clientX value to get the page coordinate.

I don't like the "assume" parts of this but maybe this is where
straight feature detection breaks down. The feature may be there but
the feature doesn't work properly. Safari has at least a few instances
of this problem.

I can imagine that we need to test that not only every feature we want
to use exists but that it works properly also. Yikes!

Peter

[Richard Cornford]

Peter Michaux wrote:

I just did a bunch of testing and was surprised with
the results. If anyone doesn't know this stuff here is
what I found about event.clientX.

The event.clientX property in Safari is in page coordinates.
In IE, Opera, Firefox event.clientX it is in window
coordinates.

That is an old and re-occurring bug. It was, for example, true of all
scriptable Opera browsers up to version 6.

This means a lot when trying to determine event location
in page coordinates. It seems best to use the old
event.pageX property first if it is a number.

And as the bug is not new it is already normal for people who know heat
they are doing to use pageX/Y in preference to clientX/Y+scrolling
whenever it is available.

This works in Safari. This is how the quirksmode
org and Yahoo! UI scripts work anyway but not Flanagan's
fifth edtion.

Flanagan 's book is only the least bad javascript book available, you
should not expect to learn good browser scripting practices from it,
only how javascript works in general at best.

If the browser doesn't have event.pageX or it isn't a
number

If it has the property it really should be a number.

then hopefully we can assume that if event.clientX exists

Why assume that?

and is a number
that clientX is in window coordinates.

You just made the wrong assumption for Opera <= 6.

Then add the amount of page
scroll to the clientX value to get the page coordinate.

If the event has no pageX/Y and does have a clientX/Y and the clientX/Y
is reporting client-area co-ordinates then adding the scroll offsets
will normalise the co-ordinates to the preferred page co-ordinates
(having adjusted for the borders of the 'root' element, if necessary
(else you get the 2 pixel discrepancy in default IE configurations) ).

I don't like the "assume" parts of this but maybe this
is where straight feature detection breaks down.

You are thinking of feature detection in terms of verifying the
existence of properties. In practice it has always involved verifying
significant aspects of the behaviour of browser object models, those are
also features of the browser.

The feature may be there but the feature doesn't work
properly.

Can you find a formal standard that says what values the clinetX/Y
properties of an event object are supposed to report? Without that there
is no meaning to "properly".

Safari has at least a few instances
of this problem.

I can imagine that we need to test that not only every
feature we want to use exists but that it works properly
also. Yikes!

Not every feature, but certainly the ones that are known to be
problematic. Of course that implies a necessity to know which features
are problematic, but practice in trying to write genuinely cross-browser
code, and properly testing it, will reveal the issues to the interested
student. And there is always reading comp.lang.javas cript and engaging
with the group.

Richard.

[Peter Michaux]

Hi Richard,

Richard Cornford wrote:

>
If the event has no pageX/Y and does have a clientX/Y and the clientX/Y
is reporting client-area co-ordinates

How is it possible to detect if the clientX number value is in page or
client-area coordinates?

then adding the scroll offsets
will normalise the co-ordinates to the preferred page co-ordinates
(having adjusted for the borders of the 'root' element, if necessary
(else you get the 2 pixel discrepancy in default IE configurations) ).

This 2 px business confused the heck out of me a few weeks back. What
are these 2 px and are they there for a reason?

It turned out that I didn't need to worry about these 2 px because the
value I was reading and the value I was setting were both working
within this 2 px discrepancy. When does this 2 px business cause
unexpected results or grief or does it always seem to cancel out?
Thank you,
Peter

[Peter Michaux]

Hi Richard,

Peter Michaux wrote:

>
Richard Cornford wrote:

If the event has no pageX/Y and does have a clientX/Y and the clientX/Y
is reporting client-area co-ordinates

How is it possible to detect if the clientX number value is in page or
client-area coordinates?

I can't imagine it is possible to look at just one number and see if it
is in page or client-area coordinates. So there must be a bit of
browser sniffing to know that Opera <=6 is involved. I have a gateway
conditional to my script that will only allow access if the browser
supports window.addEvent Listener or window.attachEv ent and my tests
show that the later was not supported until Opera 7. So this may be a
moot issue for me unless I learn of other browsers that have similar
differences. That said, I still feel uncomfortable that another browser
might appear that has problems.

then adding the scroll offsets
will normalise the co-ordinates to the preferred page co-ordinates
(having adjusted for the borders of the 'root' element, if necessary
(else you get the 2 pixel discrepancy in default IE configurations) ).

This 2 px business confused the heck out of me a few weeks back. What
are these 2 px and are they there for a reason?

It turned out that I didn't need to worry about these 2 px because the
value I was reading and the value I was setting were both working
within this 2 px discrepancy. When does this 2 px business cause
unexpected results or grief or does it always seem to cancel out?

In IE I am definitely using this coordinate system (clientX +
pageScrollX) as a fixed reference frame from which I make relative
comparisons of, say, the mouse position now and before. The absolute
values are not important so the 2px is not important. I am interested
to see if I can get away with this forever or not. From the positioning
experiements I have done it seems best to use comparisons whenever
possible to cancel out and/or avoid any browser weirdness.

I did find an old post or yours from 2003 where you were looking into
the 2px in detail. I was wondering if that little bevel in IE meant
anything. Reading your post it seems you decided those were the 2
pixels in question.

http://groups.google.com/group/comp....44f181aac86c37

Thank you,
Peter

[Richard Cornford]

Peter Michaux wrote:

Peter Michaux wrote:

>Richard Cornford wrote:

>>>
If the event has no pageX/Y and does have a clientX/Y
and the clientX/Y is reporting client-area co-ordinates

How is it possible to detect if the clientX number value
is in page or client-area coordinates?

I can't imagine it is possible to look at just one number
and see if it is in page or client-area coordinates.

If you going to normalize client co-ordinates into page co-ordinates
then you are not dealing with just one number.

Remember that, for example, when the corresponding scroll value is zero
the difference between client-area and page co-ordinates is zero. So
some of the time you don't need to know the difference, and as soon as
you do need to know you have more information to make the judgement on
(i.e. if the clientX/Y is smaller than the scrollLeft/Top then they must
be client-area co-ordinates not page co-ordinates).

It is also the case that you only need to determine whether clientX/Y
are page or client-area co-ordinates with certainty once, as they will
not change within a single browser execution environment.

So there must be a bit of
browser sniffing to know that Opera <=6 is involved.

Get some practice applying reasoning to you browser scripting problems
and you won't see the need to retreat to browser sniffing quite often.

I have a gateway conditional to my script that will only
allow access if the browser supports window.addEvent Listener
or window.attachEv ent and my tests show that the later was not
supported until Opera 7.

That is 'object inference'.

So this may be a moot issue for me unless I learn of
other browsers that have similar differences.

You can arrange to never learn of other browsers with similar issues by
the simple expedient of never looking (that is quite a popular strategy
;)

That said, I still feel uncomfortable that another
browser might appear that has problems.

>>then adding the scroll offsets will normalise the
co-ordinates to the preferred page co-ordinates
(having adjusted for the borders of the 'root' element,
if necessary (else you get the 2 pixel discrepancy in
default IE configurations) ).

This 2 px business confused the heck out of me a few weeks
back. What are these 2 px

The borer on the 'root' element (the root element varies depending on
the rendering mode in IE 6+). The default in 2px (at least on 'classsic'
windows), but can be modified by adjusting the window borders
configuration on windows.

>and are they there for a reason?

Things would have been easier if hey had never been manifest in the IE
DOM.

>It turned out that I didn't need to worry about these 2 px
because the value I was reading and the value I was setting
were both working within this 2 px discrepancy.

When the difference is what is important then consistent discrepancies
cancel themselves out. If you intend to relate the absolute position of
elements on a page with mouse co-ordinates then it is necessary to
account for the discrepancy.

>When does this 2 px business cause
unexpected results or grief or does it always seem to cancel out?

In IE I am definitely using this coordinate system (clientX +
pageScrollX) as a fixed reference frame from which I make relative
comparisons of, say, the mouse position now and before.

<snip>

If you are only interested in the differences between, say mousedown and
mouseup events in the browser window (without the page being scrolled or
the window moved in-between) then screenX/Y co-ordinates are sufficient
for the task. Then no normalisation is required at all.

Richard.

[Peter Michaux]

Richard Cornford wrote:

Peter Michaux wrote:

then hopefully we can assume that if event.clientX exists

Why assume that?

and is a number
that clientX is in window coordinates.

You just made the wrong assumption for Opera <= 6.

Do you know of any browsers other than Opera <=6 where clientX is not
in window (ie client-area) coordinates?

Can you find a formal standard that says what values the clinetX/Y
properties of an event object are supposed to report? Without that there
is no meaning to "properly".

At least I am in good company with this error. :)

http://groups.google.com/group/comp....44f181aac86c37

I can imagine that we need to test that not only every
feature we want to use exists but that it works properly
also. Yikes!

Not every feature, but certainly the ones that are known to be
problematic.

I agree with this pragmatic approach but this approach results in
somewhat brittle scripts that may break in a future browser. If the
developer knows all problematic features in all existing browsers then
the resulting scripts would not be very brittle but still brittle to
some degree. So with this approach, which is probably the only
practical one with even moderately complex scripts, there is no way to
proclaim a script is cross-browser. The best possible claim would be
multi-browser where multi means all browsers in existence and known to
the developer.

If you going to normalize client co-ordinates into page co-ordinates
then you are not dealing with just one number.

Remember that, for example, when the corresponding scroll value is zero
the difference between client-area and page co-ordinates is zero. So
some of the time you don't need to know the difference, and as soon as
you do need to know you have more information to make the judgement on
(i.e. if the clientX/Y is smaller than the scrollLeft/Top then they must
be client-area co-ordinates not page co-ordinates).

This example doesn't seem to be enough information in all cases. If the
browser window is scrolled only one pixel then this approach wouldn't
work. I imagine you have other plans if needed.

I can see setting up a very elaborate grid of invisible divs 1px wide
or tall with known positions and comparing the mouseover event
coordinates with the known position of the div in question.

When the window is scrolled, I could try to place a little invisible
div under the mouse based on the clientX information alone. If the next
mousemove is over the little div then clientX is in page coordinates.

This seems ridiculous and probably is especially in light of your
earlier pragmatic advice: since Opera <=6 cannot use my script and if
all other browsers without pageX and with clientX give clientX in
client-area coordinates then I don't need to worry or go to such great
lengths.

You can arrange to never learn of other browsers with similar issues by
the simple expedient of never looking (that is quite a popular strategy
;)

It is an endless stream of browser installations on my computer. It is
all interesting but it definitely is a very time consuming task to
learn to write quality browser scripts. And learning is likely an
unending process.

I can understand the appeal of the Yahoo! A-grade browser list to
alleviate testing tedium and compatibility/bug issues.

http://developer.yahoo.com/yui/artic...ser-chart.html

The biggest problem with this list is the Yahoo! UI library's use of
the list. They really don't follow this graded browser strategy at all
except for the A-grade browsers. If I have a C-grade browser then parts
of the Yahoo! UI library will be defined even though they won't work. A
script based on Yahoo! UI could work up to a certain stage and then
break meaning the page is useless.

The list is also very limited and it is not apparent what they expect
to happen if another browser is used. The only conclusion I can make is
they don't care. Which means, for example, they don't care about Safari
1.3 which I think is strange. I know someone still using Mac IE 5.

Peter