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

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

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.

On Sun, 29 Aug 2004 16:14:33 -0300, Nicolás Lichtmaier
<nick (AT) reloco (DOT) 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.

JRS: In article <2peo8rFjk1ciU1 (AT) uni-berlin (DOT) de>, dated Sun, 29 Aug 2004
16:14:33, seen in news:comp.lang.javascript, =?ISO-8859-15?Q?Nicol=E1s_L
ichtmaier?= <nick (AT) reloco (DOT) 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 <drunclear (AT) hotWIPETHISmail (DOT) 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.