Making your page compatible with Mozilla (and standards)

Discussion in 'Javascript' started by Nicolás Lichtmaier, Jul 24, 2004.

  1. 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 Lichtmaier, Jul 24, 2004
    #1
    1. Advertising

  2. Nicolás Lichtmaier

    Ivo Guest

    "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
    Ivo, Jul 25, 2004
    #2
    1. Advertising

  3. Nicolás Lichtmaier

    DU Guest

    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/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.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/doctorunclear/HTMLJavascriptCSS/ScreenXYComparedScreenLeftTop.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/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">Hello world!</p>
    document.getElementById("idText").innerText
    can be replaced with
    document.getElementById("idText").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 "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
    DU, Aug 2, 2004
    #3
  4. Nicolás Lichtmaier

    DU Guest

    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-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
    DU, Aug 2, 2004
    #4
  5. > 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/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.


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


    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-Level-3-Core-20040407/core.html#Node3-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.nodeValue
    > 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!
    Nicolás Lichtmaier, Aug 21, 2004
    #5
  6. 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.
    Thomas 'PointedEars' Lahn, Aug 21, 2004
    #6
  7. 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 <>'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!
    Nicolás Lichtmaier, Aug 29, 2004
    #7
  8. On Sun, 29 Aug 2004 16:14:33 -0300, Nicolás Lichtmaier
    <> 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.
    Michael Winter, Aug 29, 2004
    #8
  9. JRS: In article <>, dated Sun, 29 Aug 2004
    16:14:33, seen in news:comp.lang.javascript, =?ISO-8859-15?Q?Nicol=E1s_L
    ichtmaier?= <> 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 <>'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/draft-ietf-usefor-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.
    Dr John Stockton, Aug 30, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pai
    Replies:
    1
    Views:
    1,021
    Peter Blum
    Apr 23, 2004
  2. Aaron

    compatible with mozilla

    Aaron, Sep 7, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    526
    Kevin Marshall
    Sep 7, 2004
  3. James_patageul
    Replies:
    2
    Views:
    1,705
    Curt_C [MVP]
    Nov 16, 2004
  4. Vincent van Beveren
    Replies:
    2
    Views:
    158
  5. pantagruel
    Replies:
    0
    Views:
    236
    pantagruel
    Feb 17, 2006
Loading...

Share This Page