e.layerX problem on Macintosh browsers

[Mathieu Maes]

I have developed a page with javascript which has a filmstrip look-
alike bar and a slideshow:
http://celtecbe.apache02.hostbasket.com/pdw/media.php?id=268

It uses a "onmousemove" event, which controls the strip's scrolling
according the mouse position.

This strip seems to work just fine on IE 6, IE 7, Opera, Firefox and
Safari for Windows. However, it's not working properly on Macintosh
platform browsers (Tested on Safari and Firefox).

I'm especially astonished that the OS platform is interfering with
this, meaning that it works perfectly in FF on windows, but not on
Mac.

Since I don't own a macintosh, it's really difficult to solve this
problem. Some help is greatly appreciated.



Kind regards,
Mathew

 

[Thomas 'PointedEars' Lahn]

I have developed a page with javascript which has a filmstrip look-
alike bar and a slideshow:

There is no "javascript".

http://celtecbe.apache02.hostbasket.com/pdw/media.php?id=268

It uses a "onmousemove" event, which controls the strip's scrolling
according the mouse position.

That's a `mousemove' event; `onmousemove' is the name of this event's
handler attribute.

This strip seems to work just fine on IE 6, IE 7, Opera, Firefox and
Safari for Windows. However, it's not working properly on Macintosh
platform browsers (Tested on Safari and Firefox).
[...]
Since I don't own a macintosh, it's really difficult to solve this
problem. Some help is greatly appreciated.

Your markup is far from being Valid in the first place. Don't use XHTML if
you don't know what you are doing.

<http://validator.w3.org/check?uri=h...asket.com/pdw/media.php?id=268&ss=1;verbose=1>


HTH

PointedEars

 

[Mathieu Maes]

There is no "javascript".

That's a `mousemove' event; `onmousemove' is the name of this event's
handler attribute.

Your markup is far from being Valid in the first place.  Don't use XHTML if
you don't know what you are doing.

Thanks for those far from ontopic (but valid) remarks.

 

[Thomas 'PointedEars' Lahn]

There is no "javascript".
[...]
That's a `mousemove' event; `onmousemove' is the name of this event's
handler attribute.
[...]
Your markup is far from being Valid in the first place. Don't use XHTML if
you don't know what you are doing.

Thanks for those far from ontopic (but valid) remarks.

Those remarks are all very on-topic.

1. You are dealing with several ECMAScript implementations which behavior
differs from one another despite their similarities.

2. There is a difference between event, event handler, and event listener.

3. You cannot expect a DOM-related script to work properly from within or
on invalid markup.

Now either get yourself informed and learn to quote, or go away, please.


PointedEars

 

[Martin Rinehart]

Can't help re Mac, but you may find this useful. W3C has defined a
nice, clean opacity treatment. Just set element.style.opacity to a
value between 0 and 1.

-------------------------------------------------

// set the opacity for different browsers
// Konqueror had, then lost, opacity capability
function setOpacity( opacity, id ) {
/* Stuff like this is vital to know and takes forever to ferret
out.
Thanks, brainerror. */

if ( opacity < 0 ) opacity = 0;
if ( opacity > 1 ) opacity = 1;

object = document.getElementById( id )

if ( object && object.style ) {
var style_ = object.style;

style_.opacity = opacity;// most modern browsers
style_.MozOpacity = opacity; // original Mozilla
style_.KhtmlOpacity = opacity; // older Konqueror, Safari
style_.filter = "alpha(opacity=" + (100*opacity) + ")"; //
guess who
}

} // end of setOpacity()

 

[David Mark]

I have developed a page with javascript which has a filmstrip look-
alike bar and a slideshow:http://celtecbe.apache02.hostbasket.com/pdw/media.php?id=268

It uses a "onmousemove" event, which controls the strip's scrolling
according the mouse position.

This strip seems to work just fine on IE 6, IE 7, Opera, Firefox and
Safari for Windows. However, it's not working properly on Macintosh
platform browsers (Tested on Safari and Firefox).

I'm especially astonished that the OS platform is interfering with

The OS platform is not interfering. You have done something wrong and
it just happened to work in the five Windows browsers tested.

this, meaning that it works perfectly in FF on windows, but not on
Mac.

You should elaborate on that.

 

[Mathieu Maes]

I managed to implement a workaround in the previously given address.

I used event.pageX instead of event.layerX. pageX seems to work just
fine if I simply extract the left margin from the returned value.
However, this is not a solution. I've been getting this
"script" (whatever you wish to call it) to work on a centered page,
where the pageX value can't be used for this purpose.

An example:
http://www.kalamu.be/nl/portfolio/bedrijfscommunicatie

Anyone here who could help me find a workaround ? Since I don't own a
mac (yes yes, boohoo, shame on me) it's very hard for me to do tests.

Kind regards,
Mathew

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Sun,

Mathieu Maes wrote:

Now either get yourself informed and learn to quote, or go away, please.

Mathieu : Ignore the rudeness of the psychologically abnormal. He is
not representative of the rest of us, with one obvious possible
exception.

 

[Thomas 'PointedEars' Lahn]

I managed to implement a workaround in the previously given address.

I used event.pageX instead of event.layerX. pageX seems to work just
fine if I simply extract the left margin from the returned value.

No surprise here. The layer* properties originate from the (borken)
Netscape 4 DOM, and are therefore deprecated nowadays.

However, this is not a solution. I've been getting this
"script" (whatever you wish to call it) to work on a centered page,
where the pageX value can't be used for this purpose.

You can use the offset* properties with iteration/recursion to determine the
left top coordinate of the target element relative to the viewport (like the
page* properties). You will have to consider computed paddings, borders,
and margins, in that order.

[...]
Anyone here who could help me find a workaround ? Since I don't own a
mac (yes yes, boohoo, shame on me) it's very hard for me to do tests.

Not owning a Mac is not a problem (JFTR: I don't); not having access to one
and doing Web development anyway is.

However, I am still not convinced the chief cause of your problems is the
different operating system.


PointedEars

 

[Mathieu Maes]

The OS platform is not interfering.  You have done something wrong and
it just happened to work in the five Windows browsers tested.


You should elaborate on that.

The above script works fine on Firefox for windows, but not on Firefox
for mac. I meant to say that strangely enough there's a difference in
behavior between the PC version and the Mac version, even though (as
far as I know).


I've also made the page valid XHTML. Can anyone check if this has made
any difference ?
http://celtecbe.apache02.hostbasket.com/pdw/media.php?id=289

 

[Thomas 'PointedEars' Lahn]

[attribution lines restored]

The above script works fine on Firefox for windows, but not on Firefox
for mac. I meant to say that strangely enough there's a difference in
behavior between the PC version and the Mac version, even though (as far
as I know).

Possibility: Firefox version numbers differ.

I've also made the page valid XHTML. Can anyone check if this has made
any difference ?
http://celtecbe.apache02.hostbasket.com/pdw/media.php?id=289

Works fine in Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US;
rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3.


Please read the FAQ Notes on how to quote properly:

<http://jibbering.com/faq/faq_notes/clj_posts.html>


PointedEars

 

[David Mark]

The above script works fine on Firefox for windows, but not on Firefox

That is not an elaboration.

for mac. I meant to say that strangely enough there's a difference in

What is the difference?

behavior between the PC version and the Mac version, even though (as
far as I know).

There are lots of little differences between FF Mac and FF Windows.
FF Mac has more bugs as well.

I've also made the page valid XHTML. Can anyone check if this has made

Why? Are you serving it as XHTML? If so, you do know that IE will
open a "Save As" dialog in response to that.

 

[Thomas 'PointedEars' Lahn]

There are lots of little differences between FF Mac and FF Windows.
FF Mac has more bugs as well.

Care to elaborate on that?

Why? Are you serving it as XHTML? If so, you do know that IE will
open a "Save As" dialog in response to that.

To be fair, it was something similar to XHTML in the first place, so the
emphasis would be on "valid" now, which is in itself a Good Thing.

But yes, XHTML should not be used unless required, even though IE/MSHTML
will only show that dialog (hmm, you got the general meaning now ;-)) if it
is served as Content-Type: application/xhtml+xml and the like. (As for me,
acceptable requirements for using XHTML and serving it as text/html anyway
include XML-based server-side template engines.)


PointedEars

 

[David Mark]

Care to elaborate on that?

On bugs in FF Mac? Start with the rendering woes. Scrollbars can
bleed through absolutely positioned elements for one. Flash movies
have similar problems. Clearly the Windows version is a higher
priority for them (or they just can't code a Mac application.)

To be fair, it was something similar to XHTML in the first place, so the

That doesn't make it right. Whenever I see this on the Web, I take it
as a sign that the developers' only proficiency is using the
clipboard.

emphasis would be on "valid" now, which is in itself a Good Thing.

Valid XHTML that will ultimately be error corrected to HTML is
useless.

But yes, XHTML should not be used unless required, even though IE/MSHTML
will only show that dialog (hmm, you got the general meaning now ;-)) if it

You are such a pinhead.

 

[Thomas 'PointedEars' Lahn]

Care to elaborate on that?

On bugs in FF Mac? Start with the rendering woes. Scrollbars can
bleed through absolutely positioned elements for one. Flash movies
have similar problems. [...]

Thanks, I'll keep that in mind.

That doesn't make it right. Whenever I see this on the Web, I take it
as a sign that the developers' only proficiency is using the
clipboard.

Do you understand what "To be fair, ... But yes, ..." means? I guess
anybody else did.

Valid XHTML that will ultimately be error corrected to HTML is
useless.

That depends. And you don't know how it is being served in this case to
begin with.

You are such a pinhead.

Your smiley detector is borken.


PointedEars

 

[David Mark]

On bugs in FF Mac?  Start with the rendering woes.  Scrollbars can
bleed through absolutely positioned elements for one.  Flash movies
have similar problems.  [...]

Thanks, I'll keep that in mind.

Other than those sorts of things, apps cross over to Mac pretty well
in FF. I spent years without a Mac and now that I have one, I am
pleased to see that most of my stuff runs perfectly on FF Mac, as well
as Safari. I will never buy a PC again, that is for sure. I hate
that guy.

Do you understand what "To be fair, ...  But yes, ..." means?  I guess
anybody else did.

Yes, yes, yes.

That depends.  And you don't know how it is being served in this case to
begin with.

LOL. Would you care to place a wager on it?

Your smiley detector is borken.

Are you incapable of expressing yourself in prose?

And BTW, you reversed yourself on the whole "user action" argument
here. Leave it alone.

 

[Mathieu Maes]

You can use the offset* properties with iteration/recursion to determine the
left top coordinate of the target element relative to the viewport (like the
page* properties). You will have to consider computed paddings, borders,
and margins, in that order.

I've seen a library reconstructing the screen* properties using the
offset* properties. Having to process all the relevant properties as
mentioned seems to be rather a lot of code for a relatively simple
goal. If no alternatives exist, I'll probably look into this method
though...

Why? Are you serving it as XHTML? If so, you do know that IE will
open a "Save As" dialog in response to that.

Why not use it ? It seems to work just fine to me.
I won't go into detail about this, but in my experience I found it to
be much easier to work with. Maybe I just like my work to be more
"stricter and cleaner" ?

Can you provide any relevant documentation that supports your
arguments ?

Works fine in Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US;
rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3.

Good to hear. I've got my hands on a MiniMac for now, and I can
confirm it works in FF 3.0.3. Still no luck with Safari (version
3.1.2) though.

Please read the FAQ Notes on how to quote properly:
<http://jibbering.com/faq/faq_notes/clj_posts.html>

Read it, don't know what I'm doing wrong... using Google Groups.

 

[David Mark]

I've seen a library reconstructing the screen* properties using the
offset* properties. Having to process all the relevant properties as
mentioned seems to be rather a lot of code for a relatively simple
goal. If no alternatives exist, I'll probably look into this method
though...


Why not use it ? It seems to work just fine to me.

That is because you are serving it as text/html. In other words, it
is not treated as XHTML by any known browser, so for virtually all
intents and purposes, you are not using XHTML.

I won't go into detail about this, but in my experience I found it to
be much easier to work with. Maybe I just like my work to be more
"stricter and cleaner" ?

No need to go into detail about your experiences with XHTML when you
are not using it. The idea that your work is "stricter and cleaner"
because you use a markup language that has to be error corrected by
every browser is ridiculous.

Can you provide any relevant documentation that supports your
arguments ?

Try searching the group for "XHTML" and "useless." Google can likely
help as well. For one, most scripts written for an HTML DOM will not
work when presented with an XHTML DOM. In other words, your design
has an identity crisis.

Good to hear. I've got my hands on a MiniMac for now, and I can
confirm it works in FF 3.0.3. Still no luck with Safari (version
3.1.2) though.


Read it, don't know what I'm doing wrong... using Google Groups.

At least you admit it. Now figure out what you are doing.

 

[Thomas 'PointedEars' Lahn]

I did not write that.

Why not use it ? It seems to work just fine to me.

Yes, it only seems to be so.

I won't go into detail about this, but in my experience I found it to
be much easier to work with. Maybe I just like my work to be more
"stricter and cleaner" ?

Or maybe you just didn't know what you are doing (as if that wasn't obvious
since you had no Valid markup in the first place) because yours is a classic
wannabe's argument. Serving XHTML 1.0 as text/html is not stricter or
cleaner in any sense in the end than serving Valid HTML 4.01 in the first
place. There are benefits in doing the former on the Web, but they are
certainly not located client-side.

Can you provide any relevant documentation that supports your
arguments ?

I, among others, have done that repeatedly already. STFW.

Good to hear. I've got my hands on a MiniMac for now, and I can
confirm it works in FF 3.0.3. Still no luck with Safari (version
3.1.2) though.

I can test it tomorrow.

Read it, don't know what I'm doing wrong... using Google Groups.

Looks like at least partially you do know because you did not repeat the
mistake of removing the attribution here. You should read it again to find
out the rest; sorry, this just isn't Usenet 101.


PointedEars