views:

103

answers:

4

I am developping an AJAX website. Now I've ran into some differences between Standard JavaScript and Microsoft's JavaScript dialect.

For examle .textContent (standard) vs .text (microsoft) I could make two files, one for standard browsers and one for microsoft browsers, but if I make a change I need to do so twice, so, that's not an ideal option. Putting if statements around each time I encounter an .textContent doesn't seem like an optimal solution either.

So, I was thinkng about a script based solution, and I came up with something like this:


function translate_to_msie_dialect(){
    var s = document.getElementsByTagName("script");
    var l = s.length;
    var i;
    for ( i = 0 ; i < l ; i ++ ) {
        var src = s[i].text;
        s[i].text = src.replace(/.textContent/g, ".text");
    }
  }


I have tested this code on Internet Explorer version 8, and it seems to be doing it's job. (translating from ie to standard doesn't seem to work, standard browsers seem to execute the unaltered code instead)

The problem is, this only works for in-line scripts, and not for js source file scripts. Is it possible to do this conversion scripts for javascript files client side?

I could do a check on the user agent (server side), but I would rather do a check on the dialect itself, as some browsers support an 'identify as' feature and if they identify themselves as ie, they might get in a dialect they don't understand.

+1  A: 

Instead, you can make a getText function and assign the function in an if statement to a browser-specific implementation.

For example:

if (typeof document.body.textContent === 'undefined')
    getText = function(element) { return element.innerText; }
else
    getText = function(element) { return element.textContent; }

Alternatively, you can use a cross-browser Javascript library such as jQuery which handles all of this for you.

SLaks
-1 no UA sniffing please.
galambalazs
@galambalazs: Now are you happy?
SLaks
Yep, I've removed the vote.
galambalazs
+2  A: 

Why not benefit from the headaches already experienced by others? You're not the first to run into these cross-browser oddities. Please use a library like jQuery, which fixes this stuff for you. Then you can focus on more important things :)

Josh Stodola
+2  A: 

There are two ways to approach this problem:

1. Define a getter function

function getText(el) {
  return el.textContent || el.innerText;
}

usage

var text = getText(el);

2. Dummy test (executed only once)

var textContent = (function() { 
  var dummy = document.createElement("span");
  dummy.innerHTML = "full <span>support</span>";
  if (dummy.textContent === "full support") {
     return "textContent";
  } else {
     return "innerText";
  }
})();

usage

var text = el[textContent];

None of these will cause you performance problems I can assure you. Moreover, the two methods can be combined into one so that the correct property is decided once and the function always returns it.

Also note that the second one is not only more performant, it is safer too, because it checks correct functionality instead of existence of the property.

galambalazs
+1  A: 

Let's use Javascript to its full potential, something difficult to do with IE, but not with other browsers.

if (typeof HTMLElement != 'undefined')
  HTMLElement.prototype.__defineGetter__('innerText', function() {
    return this.textContent;
  });

With this you can use innerText in non-IE browsers with consistent results.

Just another method to consider. I will say, some may warn of the eeevils of modifying the prototypes of hosted objects (I await the downvotes). I would respectfully disagree however, since this is a compatibility shim targeted at non-IE browsers, which all behave correctly in this regard.

MooGoo
I won't vote you down, but you deserve it. Messing with *Host objects* is **not** an IE only problem. The main point is that *`exposure of “prototype objects” is not part of any specification`*, also *`internal methods behavior is implementation-dependent`*. For more informantion please **read**: http://perfectionkills.com/whats-wrong-with-extending-the-dom/
galambalazs
I've read it all, but the simple fact is, it works and works consistently in every modern browser besides IE. And there is no reason to suspect that it won't work in the future. As usual, the official specification is simply behind all decent EMCAScript implementations.
MooGoo