Making your page compatible with Mozilla (and standards)

[Nicolás Lichtmaier]

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!

[Ivo]

Re: Making your page compatible with Mozilla (and standards)

"Nicolás Lichtmaier" wrote[color=blue]
> 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![/color]

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 "Bibliograp hy" 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

[DU]

Re: Making your page compatible with Mozilla (and standards)

Nicolás Lichtmaier wrote:
[color=blue]
> 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![/color]

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 CalculatedTotal OffsetLeft = CalculatedTotal OffsetTop = 0 ;
while (Element.offset Parent)
{
CalculatedTotal OffsetLeft += Element.offsetL eft ;
CalculatedTotal OffsetTop += Element.offsetT op ;
Element = Element.offsetP arent ;
} ;

OffsetXForMozil la = evt.pageX - CalculatedTotal OffsetLeft ;
OffsetYForMozil la = evt.pageY - CalculatedTotal OffsetTop ;

In my own homepage (at this precise url; you need MSIE 6 to view it)

http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/DUWindowsMSIE6.html#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.screenLe ft, window.screenTo p

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/doctorunclear/HTMLJavascriptCSS/ScreenXYComparedScreenLeftTop.html

4- document.defaul tView is NOT the equilavent of document.parent Window.
document.conten tWindow is the equivalent to document.parent Window
Note here:

See/try

http://bugzilla.mozilla.org/attachment.cgi?id=140109&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-Level-3-Core-20040407/core.html#Node3-textContent

I think your document should just give an example of how to replace
innerTtext with a working example.
E.g.:
<p id="idText">Hel lo world!</p>
document.getEle mentById("idTex t").innerTex t
can be replaced with
document.getEle mentById("idTex t").firstChild. nodeValue
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 "Parenthese s 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

[DU]

Re: Making your page compatible with Mozilla (and standards)

Nicolás Lichtmaier wrote:
[color=blue]
> 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![/color]


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-developer/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/doctorunclear/HTMLJavascriptCSS/DUWindowsMSIE6.html

DU

[Nicolás Lichtmaier]

Re: Making your page compatible with Mozilla (and standards)

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

Thanks! Sorry for the late reply! =)
[color=blue]
> 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.[/color]

I don't undesrtand this. Isn't the same?
[color=blue]
> 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 CalculatedTotal OffsetLeft = CalculatedTotal OffsetTop = 0 ;
> while (Element.offset Parent)
> {
> CalculatedTotal OffsetLeft += Element.offsetL eft ;
> CalculatedTotal OffsetTop += Element.offsetT op ;
> Element = Element.offsetP arent ;
> } ;
>
> OffsetXForMozil la = evt.pageX - CalculatedTotal OffsetLeft ;
> OffsetYForMozil la = evt.pageY - CalculatedTotal OffsetTop ;
>
> 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.[/color]

My text, although a bit imprecise, was useful. I corrected it a bit.
What do you think now?
[color=blue]
> 3- window.screenX, window.screenY are not the equivalent to MSIE's
> window.screenLe ft, window.screenTo p
>
> 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[/color]

I see theses properties specify the coordinates of different points in
the window. I've noted that in my page.
[color=blue]
> 4- document.defaul tView is NOT the equilavent of document.parent Window.
> document.conten tWindow is the equivalent to document.parent Window
> 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[/color]

From a pragmatic point of view, "defaultVie w" 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?
[color=blue]
> 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[/color]

Right. This property wasn't there in Mozilla when I wrote the page. I'll
update it.
[color=blue]
> I think your document should just give an example of how to replace
> innerTtext with a working example.
> E.g.:
> <p id="idText">Hel lo world!</p>
> document.getEle mentById("idTex t").innerTex t
> can be replaced with
> document.getEle mentById("idTex t").firstChild. nodeValue
> Depending on the specific need of the scripter, some CharacterData
> method might be more relevant to use.[/color]

I'm already providing an example!
[color=blue]
>
> 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 "Parenthese s or brackets" section, you write
> "One must always use [], i.e.: documents.forms[0].field.value"[/color]

I've changed "must" to "may".
[color=blue]
>
> Finally, I invite you to participate (feedback, suggestions, ideas) in
> bug 74952.[/color]

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!

[Thomas 'PointedEars' Lahn]

Re: Making your page compatible with Mozilla (and standards)

Nicolás Lichtmaier wrote:
[color=blue][color=green]
>> Here's some feedback and improvement suggestions on your page.[/color]
>
> Thanks! Sorry for the late reply! =)[/color]

Whose posting are you replying to? Please provide proper attribution,
see the <http://jibbering.com/faq/> and an example of such above.
[color=blue][color=green]
>> 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.[/color]
>
> I don't undesrtand this. Isn't the same?[/color]

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.

[Nicolás Lichtmaier]

Re: Making your page compatible with Mozilla (and standards)

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Whose posting are you replying to? Please provide proper attribution,
> see the <http://jibbering.com/faq/> and an example of such above.[/color]

Sorry, I was replying to du <drunclear@hotW IPETHISmail.com >'s mail from
01/08/2004.
[color=blue]
> 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.[/color]

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!

[Michael Winter]

Re: Making your page compatible with Mozilla (and standards)

On Sun, 29 Aug 2004 16:14:33 -0300, Nicolás Lichtmaier
<nick@reloco.co m.ar> wrote:

[snip]
[color=blue]
> 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? =)[/color]

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_NOD E will return undefined on most browsers. IE will
also choke on Node.ELEMENT_NO DE. 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.

[Dr John Stockton]

Re: Making your page compatible with Mozilla (and standards)

JRS: In article <2peo8rFjk1ciU1 @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?= <nick@reloco.co m.ar> posted :[color=blue]
>Thomas 'PointedEars' Lahn wrote:[color=green]
>> Whose posting are you replying to? Please provide proper attribution,
>> see the <http://jibbering.com/faq/> and an example of such above.[/color]
>
>Sorry, I was replying to du <drunclear@hotW IPETHISmail.com >'s mail from
>01/08/2004.[/color]


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.demo n.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.