471,337 Members | 986 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,337 software developers and data experts.

Making your page compatible with Mozilla (and standards)

Hi, some time ago I've written an article about this issue. It explain
some differences in Explorer's and Mozilla's JavaScript/DOM. It has
recently changed its URL, This is the new one:

http://www.reloco.com.ar/mozilla/compat.html

Bye!

PS: I hope it's useful to someone. I would appreciate any comments and
suggestions!
Jul 23 '05 #1
8 2800
Ivo
"Nicolás Lichtmaier" wrote
Hi, some time ago I've written an article about this issue. It explain
some differences in Explorer's and Mozilla's JavaScript/DOM. It has
recently changed its URL, This is the new one:

http://www.reloco.com.ar/mozilla/compat.html

Bye!

PS: I hope it's useful to someone. I would appreciate any comments and
suggestions!


If the issue you are reffering to is the one in the subject line (which not
every newsreader displays), "Making your page compatible with Mozilla (and
standards)", then certainly there are quite a few issues.

When building a page, one should start with the standards, then see what
happens in the target browsers and react accordingly. That is another school
of thought, and a healthier one imo.

The article identifies some differences as well as similarities between
"Explorer and other browsers", but not very systematically or academically,
workarounds are presented without much fore- or afterthought, and one is
left wondering what other pitfalls are out there. On the whole, sorry but I
wonder what this adds to the myriad of articles of this nature that are
piling up around us.

The little <UL> with the link to the translation overlaps the text in my
browser (IE6). There a few inaccuracies in spelling and capitalization which
don't help to build trust, the "Bibliography" is perhaps more of a
"Reference", and a Table of Contents would be useful at the top.
The example scripts are useful, although a comment like "// let's not forget
poor Explorer" doesn't make things any clearer.
HTH
Ivo
Jul 23 '05 #2
DU
Nicolás Lichtmaier wrote:
Hi, some time ago I've written an article about this issue. It explain
some differences in Explorer's and Mozilla's JavaScript/DOM. It has
recently changed its URL, This is the new one:

http://www.reloco.com.ar/mozilla/compat.html

Bye!

PS: I hope it's useful to someone. I would appreciate any comments and
suggestions!


Nicolás,

Here's some feedback and improvement suggestions on your page.

1- srcElement: you write "The same, but in Mozilla the nodes of type
text can also fire events,(...)". That's not true. It's the target
property of the event object and there is a large consensus on the web
regarding this.

2- offsetX, offsetY (for event object): you write "If event.target is in
a normally (static) positioned element these properties will give you
the offset with respect to the page." That's not true; that's not
precise. When an object is statically positioned, then offsetLeft and
offsetTop return x and y coordinates relative to the document root
element. I would remove that sentence. What you write would be true for
objects (not event object) and for offsetLeft and offsetTop properties
and the following code would be correct:

var Element = evt.target ;
var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ;
while (Element.offsetParent)
{
CalculatedTotalOffsetLeft += Element.offsetLeft ;
CalculatedTotalOffsetTop += Element.offsetTop ;
Element = Element.offsetParent ;
} ;

OffsetXForMozilla = evt.pageX - CalculatedTotalOffsetLeft ;
OffsetYForMozilla = evt.pageY - CalculatedTotalOffsetTop ;

In my own homepage (at this precise url; you need MSIE 6 to view it)
http://www10.brinkster.com/doctorunc...l#NoteOffsetXY

, I wrote "Under NS 6+, it is possible to calculate [directly] the
offsetX/Y values." and I still think this is true.

3- window.screenX, window.screenY are not the equivalent to MSIE's
window.screenLeft, window.screenTop

If you open the explorer bar or activate the Tip of the day frame,
you'll see that values are different, they change. If you open the
sidebar in Mozilla, window.screenX won't change.

http://www10.brinkster.com/doctorunc...enLeftTop.html

4- document.defaultView is NOT the equilavent of document.parentWindow.
document.contentWindow is the equivalent to document.parentWindow
Note here:

See/try
http://bugzilla.mozilla.org/attachme...09&action=view
from bug 151300 at bugzilla.
Also, bug 228497: contentWindow is not implemented on document
http://bugzilla.mozilla.org/show_bug.cgi?id=228497

5- innerText: "There's no direct mozilla equivalent." Strictly speaking,
that is not true as Mozilla 1.5+ implement DOM 3 Core method textContent.

http://www.w3.org/TR/2004/REC-DOM-Le...e3-textContent

I think your document should just give an example of how to replace
innerTtext with a working example.
E.g.:
<p id="idText">Hello world!</p>
document.getElementById("idText").innerText
can be replaced with
document.getElementById("idText").firstChild.nodeV alue
Depending on the specific need of the scripter, some CharacterData
method might be more relevant to use.

6- MyForm: "You must use document.myForm" The scripter might also use
document.forms["myForm"]
or even
document.forms[ordinalInteger] which will be XHTML compliant as well. I
would at least change your "must" to "may" in your file and offer the 2
other alternatives.
In your "Parentheses or brackets" section, you write
"One must always use [], i.e.: documents.forms[0].field.value"

Finally, I invite you to participate (feedback, suggestions, ideas) in
bug 74952.

DU
Jul 23 '05 #3
DU
Nicolás Lichtmaier wrote:
Hi, some time ago I've written an article about this issue. It explain
some differences in Explorer's and Mozilla's JavaScript/DOM. It has
recently changed its URL, This is the new one:

http://www.reloco.com.ar/mozilla/compat.html

Bye!

PS: I hope it's useful to someone. I would appreciate any comments and
suggestions!

I read some more your page. Here are additional comments and suggested
improvements or corrections.

1- "and will narrow the posibility of leaving a browser unsupported."
possibility 2 "s"

2- "Another common error is to check if the browser has something, and
if it doesn't to assume that it has another thing."
Suggestion: "Another common error is to check if the browser supports a
method, and, if it doesn't, to assume that it supports a particular method."
Notice the comma ","

3- "This cannot be relied upon. It's better to directly test what one is
going to use." Here, at that point, I would give a "more info" link on
this for visitors willing to know more on the subject, say:
<a href="http://jibbering.com/faq/#FAQ4_26">More info</a>

4- I would avoid negative pejoratism in expressions which do not serve
the purpose of your document.
"the ugly window.event was born", "This window.event, in addition to
being a terrible idea", "let's not forget poor Explorer"
Remember that when event as an object was introduced, there was no W3C
DOM standard and we were in browsers war. The W3C could have chosen for
the MSIE DOM event object but did not. The W3C could have chosen to
support <layer> instead of <div>. There is nothing intrinsically bad,
ugly or terrible about the MSIE event object; it's just that *now* such
event object is not part of W3C web standard DOM 2 event. And we know
that MSIE dev. team would have been happy to implement DOM 2 events but
real os dependent limitations prevented such implementations.

5- Everywhere you use "the same thing" expression, I think you should
look for a more meaningful way to explain things or re-word your sentence.

6- In your bibliography, you give Gecko DOM reference but that
documentation is IMO so poorly written, so weakly written that I would
hesitate *a lot* before giving such reference. How about giving a link to

Using Web Standards in Your Web Pages
http://www.mozilla.org/docs/web-deve...upgrade_2.html

this newsgroup FAQ,
http://jibbering.com/faq/

Peter-Paul Koch cross-browser DOM compatibility page
http://www.quirksmode.org/dom/contents.html#link2

Using the W3C DOM Level 1 Core (about DOM tree, text nodes, etc)
http://www.mozilla.org/docs/dom/technote/intro/

and maybe my own window, event property page?
http://www10.brinkster.com/doctorunc...dowsMSIE6.html

DU
Jul 23 '05 #4
> Here's some feedback and improvement suggestions on your page.

Thanks! Sorry for the late reply! =)
1- srcElement: you write "The same, but in Mozilla the nodes of type
text can also fire events,(...)". That's not true. It's the target
property of the event object and there is a large consensus on the web
regarding this.
I don't undesrtand this. Isn't the same?
2- offsetX, offsetY (for event object): you write "If event.target is in
a normally (static) positioned element these properties will give you
the offset with respect to the page." That's not true; that's not
precise. When an object is statically positioned, then offsetLeft and
offsetTop return x and y coordinates relative to the document root
element. I would remove that sentence. What you write would be true for
objects (not event object) and for offsetLeft and offsetTop properties
and the following code would be correct:

var Element = evt.target ;
var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ;
while (Element.offsetParent)
{
CalculatedTotalOffsetLeft += Element.offsetLeft ;
CalculatedTotalOffsetTop += Element.offsetTop ;
Element = Element.offsetParent ;
} ;

OffsetXForMozilla = evt.pageX - CalculatedTotalOffsetLeft ;
OffsetYForMozilla = evt.pageY - CalculatedTotalOffsetTop ;

In my own homepage (at this precise url; you need MSIE 6 to view it)
http://www10.brinkster.com/doctorunc...l#NoteOffsetXY
, I wrote "Under NS 6+, it is possible to calculate [directly] the
offsetX/Y values." and I still think this is true.
My text, although a bit imprecise, was useful. I corrected it a bit.
What do you think now?
3- window.screenX, window.screenY are not the equivalent to MSIE's
window.screenLeft, window.screenTop

If you open the explorer bar or activate the Tip of the day frame,
you'll see that values are different, they change. If you open the
sidebar in Mozilla, window.screenX won't change.

http://www10.brinkster.com/doctorunc...enLeftTop.html
I see theses properties specify the coordinates of different points in
the window. I've noted that in my page.
4- document.defaultView is NOT the equilavent of document.parentWindow.
document.contentWindow is the equivalent to document.parentWindow
Note here:

See/try
http://bugzilla.mozilla.org/attachme...09&action=view
from bug 151300 at bugzilla.
Also, bug 228497: contentWindow is not implemented on document
http://bugzilla.mozilla.org/show_bug.cgi?id=228497
From a pragmatic point of view, "defaultView" is what the reader needs:
It's implemented in "document" and it points to the right object. Is
there a case when it would be pointing somewhere else?
5- innerText: "There's no direct mozilla equivalent." Strictly speaking,
that is not true as Mozilla 1.5+ implement DOM 3 Core method textContent.

http://www.w3.org/TR/2004/REC-DOM-Le...e3-textContent
Right. This property wasn't there in Mozilla when I wrote the page. I'll
update it.
I think your document should just give an example of how to replace
innerTtext with a working example.
E.g.:
<p id="idText">Hello world!</p>
document.getElementById("idText").innerText
can be replaced with
document.getElementById("idText").firstChild.nodeV alue
Depending on the specific need of the scripter, some CharacterData
method might be more relevant to use.
I'm already providing an example!

6- MyForm: "You must use document.myForm" The scripter might also use
document.forms["myForm"]
or even
document.forms[ordinalInteger] which will be XHTML compliant as well. I
would at least change your "must" to "may" in your file and offer the 2
other alternatives.
In your "Parentheses or brackets" section, you write
"One must always use [], i.e.: documents.forms[0].field.value"
I've changed "must" to "may".

Finally, I invite you to participate (feedback, suggestions, ideas) in
bug 74952.


Thanks! =)

I appreciate all your work here, the reason that I delayed the response
was that I'm now not working with WWW related things. So I had to take
the time to study your mail. I've now made some corrections to my page
and I look forward to hear more comments.

Thank you again!
Jul 23 '05 #5
Nicolás Lichtmaier wrote:
Here's some feedback and improvement suggestions on your page.


Thanks! Sorry for the late reply! =)


Whose posting are you replying to? Please provide proper attribution,
see the <http://jibbering.com/faq/> and an example of such above.
1- srcElement: you write "The same, but in Mozilla the nodes of type
text can also fire events,(...)". That's not true. It's the target
property of the event object and there is a large consensus on the web
regarding this.


I don't undesrtand this. Isn't the same?


Yes, there is no "srcElement" property in the Gecko DOM (it is proprietary
and IE only), i.e. reading this property returns `undefined'. Instead,
this DOM implements the (W3C) DOM Level 2 Events Specification (a Web
quasi-standard) where the Event interface has a "target" attribute and thus
Event objects as passed as argument to the event listener have a "target"
property.
PointedEars
--
Beta testing BUGS me.
Jul 23 '05 #6
Thomas 'PointedEars' Lahn wrote:
Whose posting are you replying to? Please provide proper attribution,
see the <http://jibbering.com/faq/> and an example of such above.
Sorry, I was replying to du <dr*******@hotWIPETHISmail.com>'s mail from
01/08/2004.
Yes, there is no "srcElement" property in the Gecko DOM (it is proprietary
and IE only), i.e. reading this property returns `undefined'. Instead,
this DOM implements the (W3C) DOM Level 2 Events Specification (a Web
quasi-standard) where the Event interface has a "target" attribute and thus
Event objects as passed as argument to the event listener have a "target"
property.


I see, so my page http://www.reloco.com.ar/mozilla/compat.html is wrong.
I've corrected it. In my page I also say that target can be a text node,
but I'm testing now and it seems to point to the element... is my page
wrong again? =)

Thanks!
Jul 23 '05 #7
On Sun, 29 Aug 2004 16:14:33 -0300, Nicolás Lichtmaier
<ni**@reloco.com.ar> wrote:

[snip]
In my page I also say that target can be a text node, but I'm testing
now and it seems to point to the element... is my page wrong again? =)


It can be, but isn't in most browsers. I forget where I did see it.

It's probably prudent to check that the node is an element and, if it
isn't, the parent node should be obtained.

if(1 != node.nodeType) {node = node.parentNode;}

I don't think that you would need to move higher than the parent. Only an
element should be able to contain a text node (I could be wrong, though).
Also, obj.ELEMENT_NODE will return undefined on most browsers. IE will
also choke on Node.ELEMENT_NODE. The safest way to compare is to use the
actual number, 1. You could always define your own constant, or write a
function to test the element, if you don't want to start littering your
code with "magic" numbers.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #8
JRS: In article <2p************@uni-berlin.de>, dated Sun, 29 Aug 2004
16:14:33, seen in news:comp.lang.javascript, =?ISO-8859-15?Q?Nicol=E1s_L
ichtmaier?= <ni**@reloco.com.ar> posted :
Thomas 'PointedEars' Lahn wrote:
Whose posting are you replying to? Please provide proper attribution,
see the <http://jibbering.com/faq/> and an example of such above.


Sorry, I was replying to du <dr*******@hotWIPETHISmail.com>'s mail from
01/08/2004.

Lahn's example is inadequate; it does not comply with current USEFOR
thinking, as shown in
http://www.ietf.org/internet-drafts/...-useage-00.txt .
No known accepted Usenet standard restricts attributions Lahnishly ; the
German Hierarchy may prefer to work that way, but this is not yet the
Fourth Reich.

Name and E-address should be given, and further details may be given; I
include the ones I find helpful in mine.

Just consider Lahn as a juvenile Galtieri-wannabe.
Note that 01/08/2004 is ambiguous. It means one thing in America and
parts of Canada; and another in most other continents. Use the form
YYYY/MM/DD or YYYY-MM-DD for numeric dates, following ISO 8601.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Jul 23 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Steve Hoyer | last post: by
4 posts views Thread by Greg | last post: by
1 post views Thread by Elie Grouchko | last post: by
5 posts views Thread by =?Utf-8?B?V2FubmFiZQ==?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.