Browser compatibility

Discussion in 'Javascript' started by Simon Wigzell, Nov 15, 2003.

  1. I cobbled together the following function from examples on the internet to
    set named spanned items in the parent form. It works fine for IE but not at
    all for netscape. What other browser conditions do I need to test for and
    what is the correct syntax for the
    sode so that I am covered for all cases? Thanks!

    function WriteContent(name, newText)
    var browser=navigator.appName
    var version=parseInt(navigator.appVersion)

    if (browser=="Microsoft Internet Explorer")
    Simon Wigzell, Nov 15, 2003
    1. Advertisements

  2. Thanks! Looks like a big improvement on what I had.
    Simon Wigzell, Nov 15, 2003
    1. Advertisements

  3. The worst part of the internet is that there is no quality control :)
    All cases would include Javascript not being available, or that
    changing the document content isn't possible at all. I guess you are
    excluding these cases.
    If you want to use a property or object, test for it specifically
    instead of trying to guess the browser version.
    You should never use eval for accessing properties or variables. You
    will probably never need to use eval at all. The exceptions are few
    and rare, and it is a safe bet that you won't hit them.
    This is (almost) equivalent and *much* more effective:

    The "almost" refers to the case where the value of newText contains a
    single quote ('). In that case, the eval version fails.
    document.layers only exist in Netscape 4. Netscape 6+ is a complete
    rewrite (it is a branded version of the Mozilla browser) and is not
    compatible with Netscape 4.
    If newText contains a text string, and not HTML, then use the following:

    function getElem(doc,id) {
    if (doc.getElementById) {
    return doc.getElementById(id);
    } else if (doc.all) {
    return doc.all[id];
    } else if (doc.layers) {
    return doc.layers[id];
    return null; // this is not happening

    function writeContent(name,newText) {
    var doc = opener.document;
    var elem = getElem(doc,name);
    if (doc.createTextNode) { // Modern browsers
    var text = doc.createTextNode(newText);
    while(elem.hasChildNodes()) {
    } else if (elem.innerHTML) { // IE 4
    elem.innerHTML = newText; // Maybe use .innerText
    } else if (elem.document != doc) { // NS 4;
    No reference to browser name or version.
    If newText contains HTML, you will have to drop the first method,
    or parse the HTML yourself.
    Tested in Netscape 4, Mozilla FB 0.7, IE 6, and Opera 7

    Lasse Reichstein Nielsen, Nov 16, 2003
  4. HikksNotAtHome wrote:


    Where in the DOM standard is innerHTML defined? I can't find it anywhere.
    David Leverton, Nov 16, 2003
  5. It isn't. The property "innerHTML" was invented by Microsoft. Web
    authors liked it, so some other browsers (Mozilla and Opera 7) have
    also implemented it to preserve compatability with existing pages.
    It is not official DOM.

    Lasse Reichstein Nielsen, Nov 16, 2003
  6. Where in the DOM standard is innerHTML defined? I can't find it anywhere.

    It is not a standard DOM feature, but it is necessary feature because it give
    you access to the HTML parser. It is a Microsoft feature, which has also been
    adopted by Mozilla and others.
    Douglas Crockford, Nov 16, 2003
  7. [innerHTML]
    I don't see why that is necessary. Handy, yes, but necessary?

    I would prefer a function with a type like:
    DocumentFragment parseHTML(String)
    That would fit much better with the official DOM functions.

    Well, maybe in DOM v3 :)

    Lasse Reichstein Nielsen, Nov 16, 2003
  8. Though I really like innerHTML, I can only agree to your suggestion.
    FWIW, Mozilla has extended the Range model adding several useful
    features, like the createContextualFragment method, which does exactly
    what you suggest.


    Yann-Erwan Perio, Nov 17, 2003
  9. Simon Wigzell

    Jim Ley Guest

    You would also need a serialiser... Which is the other thing it does
    of course. DocumentFragment is also problematical (at least it's
    proven so in SVG where parseXML exists), then you'd need to provide a
    document context, which would mean you'd naturally need the method off
    document, or maybe on every single element? none of it sounds that
    neat from a JS perspective, I'm sure if it was simple we wouldn't be
    waiting until DOM 3 - of course DOM-3 isn't that relevant to HTML
    authoring, but in XML based stuff.
    Yes, but remember the official DOM are language agnostic, so they
    often have to fit with things that don't make for neat javascript.

    Jim Ley, Nov 20, 2003
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.