Using the innerText Property in Firefox

I’ve read on different forums questions of people asking how they can make the innerText property work in Firefox. Many have suggested to use the innerHTML property instead, but that would not be useful because, obviously, the HTML tags would be either rendered or displayed (an example of the latter would be if we want such text to be displayed in a textarea or text field) giving undesired effects.

Well, in short, Firefox does not support the innerText property. Instead, it supports the textContent property.

So, you could ‘sniff’ what browser the user is using and use the correct property accordingly.
So, you could check for the browser’s feature support to use the correct property accordingly (this is better than sniffing ;))

Example (updated):

if(document.all){
     document.getElementById('element').innerText = "my text";
} else{
    document.getElementById('element').textContent = "my text";
}

That’s it. Hope it helps ;)

J

Addendum:
See also: The textContent and innerText Properties. This post will help you to make the innerText property work in Safari too ;)

88 thoughts on “Using the innerText Property in Firefox

  1. Prof_Bab

    Man I see that u saved a lot of people. Cheers. It’s nice to find such stuff without the need to … um… learn browser specific code and stuff :). Thanks again.

  2. GreatTalents

    been pulling my hair out trying to figure out what was going, then found the innertext the problem….found this article and WALAHH! Thanks for posting the article

  3. JAW

    Just what I was looking for,

    And, I know the first commenter, Nola, above. What a small world!

    Happy New Year,

    Jonathan

  4. Jesse Perrin

    I found this other method elsewhere…

    if(document.all)
    {
    // has innerText feature
    }
    else
    {
    // does not have innerText feature…
    // use textContent instead
    }

    which is better?

  5. Juan Wong Post author

    @Jesse,

    It’s alright. I would recommend to use the other one because it’s compatible with Safari and Konqueror. You can definitelly use this function, but it won’t work in these two browsers.

    In other words, an improved and efficient ‘version’ of the code presented on this page, is the one presented on the The textContent and innerText Properties page.

    Hope this helps.

  6. Antonio Marques

    Zecc’s methos is obviously the clean one (to check for one property each time you want to use another is just not good), but not optimal since it entails a compatibility layer. This kind of functionality should be encapsulated anyway, beginning with something like:

    // must be onload, so that document.body exists
    if(typeof document.body.innerText == ‘undefined’)
    function ct(text, elm){elm.textContent=text}
    else
    function ct(text, elm){elm.innerText=text}

    and then only call

    ct(aText, anElm);

    anytime you need it.

    Browsers without document.body, innerText or textContent should be ignored, anyway. W3C standards have been out there long enough that at least their basics should be supported.

  7. Juan Wong Post author

    Antonio,

    First off, Thank you for your comment.

    Well, I think otherwise. I’m not saying Zecc’s method is not good, but that’s a method I personally wouldn’t use unless I have already deployed a website for which I would need to make the code more cross-browser compatible. Otherwise, I don’t see a specific reason why you’d have to define the innerText property for Firefox other than ‘saving’ you from writing a few lines of code in your project (which is fine too).

    In other words, the simpler the code, the better.

    You say:

    to check for one property each time you want to use another is just not good

    Why is ‘just not good’? without an explanation, saying ‘is just not good’ is just not good, because it doesn’t tell me anything. I’m more likely to understand your point of view and say “oh, that makes sense” if you actually explain why.

    You said:

    W3C standards have been out there long enough that at least their basics should be supported.

    Granted, and since you’re posting this comment on this article, and telling me the above, I’m assuming you haven’t read my other article. There, I’m doing something similar to what you’re suggesting in your code above.

    By the way, why are you defining 2 ct() functions inside an if() statement? I don’t find it efficient to write two function definitions when that can be done in one, especially for something so simple; besides, you write if() statements inside function definitions, not the other way around. Like so:

    function ct(aText, anElm){
    	if(typeof document.body.innerText == 'undefined'){
    		elm.textContent = aText;
    	} else{
    		elm.innerText = aText;
    	}
    }
    
  8. Jeremy

    what about this:

    myString = (myElement.textContent) ? myElement.textContent : myElement.innerText;

    it works ok in IE and Firefox for me.

  9. Sjors

    document.getElementById(‘myElement).firstChild.nodeValue is a bit more standards compliant

  10. Ronald B. Weasley

    I said to Harry that magic doesn’t work. So we googled and found your page. Thank you, it helped us :)

  11. David

    Great solution! This was my 3rd hit thru Google, but ran different searches to handle.

    Regarding the omission of the IF

    This would likely break in the next browser version. As soon as one browser adopts the function of the other. (whichever is more popular, or adopted by the WC3 or whatever)

  12. Juan Wong Post author

    Alex, I believe I tried that once but it didn’t work for me. I’ll try it once more and if it works, then I might’ve done something wrong before.

    Thanks for your comment.

  13. constantine

    Thanx for the solution!

    p.s.: i hate Mozilla… Why implement .innerText with other alias ? To prove that they are unique yet another time ? :/ That’s beyond my understanding…

  14. Juan Wong Post author

    Constantine,

    innerText is not a standard property, it’s a Microsoft proprietary property. However, textContent is part of the Document Object Model Core.

    Mozilla is more standards compliant than MS is, so… they’re not trying to ‘prove’ they’re unique in anyway but to follow standards as much as possible.

  15. Antonio

    Hi, Juan,

    I’ve just found your blog while browsing the Web, and guess what, I see that I’ve made a contribution before! And I think I’ve been misunderstood and that my points are important, so I’ll address them from here since it seems the original won’t take comments anymore.

    First of all, I didn’t mention thank you properly the first time, I didn’t

    I wrote the following (on harmonising e.innerText and e.textContent):

    (A method which makes innerText available in Firefox) is obviously the clean one (to check for one property each time you want to use another is just not good), but not optimal since it entails a compatibility layer. This kind of functionality should be encapsulated anyway, beginning with something like:


    // must be onload, so that document.body exists
    if(typeof document.body.innerText === ‘undefined’)
    function setText(text, elm) { elm.textContent=text }
    else
    function setText(text, elm) { elm.innerText=text }

    and then only call

    setText(aText, anElm);

    anytime you need it.

    And you objected that:

    Why is ‘just not good’ (to check for one property each time you want to use another)? without an explanation, saying ‘is just not good’ is just not good, because it doesn’t tell me anything. I’m more likely to understand your point of view and say “oh, that makes sense” if you actually explain why.

    The answer is, I didn’t explain it because I thought it was self evident. I see it isn’t, since almost nobody thinks of it. The reason is that it’s inefficient to have a check each of the thousand times you want to use a functionality, especially if it’s completely unnecessary. Someone thought of it and kept a cache of the check in a variable, and checks the variable instead. That’s maybe marginally better in terms of performance, but the matter is that the check needs to be done only *once*.

    *That* is why I put the check *outside* the function definition: if you support innerText, you’ll have one function; if you support textContent, you’ll have the other one. And from that moment on, your webpage won’t spend a nanosecond more deciding what code to run. Nor is the alternate path kept in memory.

    This may seem like a little thing, but it’s a big one. Javascript needs such checks in many places, and a single filling of a box with small elements may need hundreds of calls to code which differs between browsers. Clearly the solution is not to make the check every time. Rather, use the check while you define your functions, and end up with only those you need. Slimmer and faster.

  16. Juan Wong Post author

    Thank you, Antonio.

    I definitely believe any contribution is valuable and yours is no exception. I’m all for efficiency and your explanation is important.

    I’ll keep your comment temporarily here, when I have a chance, I’ll move it to its right place and comment in more depth there.

    I moved your comment to it’s respective post. I will open comments again and keep them open for a short time just in case you want to comment again. I closed comments on this post because it was getting a lot of spam…

    I’ll be commenting shortly.

    Just to clarify, I’m the type of person that if you tell me “this color is green”, I always want to know how come. If you tell me, “because is green, it’s a color”, it doesn’t tell me anything, but if you tell me something like “It’s green because it’s a combination of yellow and blue”, then I’ll feel good because I learned a new thing. That’s why I said “I’m more likely to understand your point of view and say “oh, that makes sense” if you actually explain why.”

    Okay, you said:

    That’s maybe marginally better in terms of performance, but the matter is that the check needs to be done only *once*.

    And I agree, we shouldn’t check that every time we call the function; that’s why, like I said in one of my previous replies to you, in my other article, I’m checking this when the page loads and keep the value in a variable:

    var hasInnerText = (document.getElementsByTagName("body")[0].innerText != undefined) ? true : false;
    

    And use it accordingly:

    function SetText(text, elm){
         if(!hasInnerText){
              elm.textContent = text;
         } else{
              elm.innerText = text;
         }
    }
    

    The way you and I do it is different but I think the idea is similar (if not the same).

    Now, there’s one thing that I don’t agree with you, if I understand what you said well, that is. I’ll quote them together because I think they’re related:

    The reason is that it’s inefficient to have a check each of the thousand times you want to use a functionality…

    Javascript needs such checks in many places, and a single filling of a box with small elements may need hundreds of calls to code which differs between browsers…

    It seems you’re thinking about this as if it the check was made on the server side. If this was server side scripting, then I would agree with you entirely; however, the check won’t be performed hundreds, much less thousands of times since it’s ran locally… on a single browser at a time. True, the page will be served thousands of times, but JavaScript won’t be ran till the browser loads the page… And I doubt you’d serve a page with hundreds of checks of this type.

    Best!

  17. Z

    I believe your fears regarding document.all are coming true… albeit slowly… isn’t it better to use getElementById or other detection in some form?

  18. Juan Wong Post author

    Z,

    Do you mean using getElementById to detect if innerText is supported? If that’s so, then no. Using getElementById is not good since all browsers support it and it’s just not correct.

    In my other article, I’m using another method to check if the innerText property is supported. You might want to check it out.

  19. Stanley

    Oh Mannnnnn….Thanx a BILLION !!! All this while i was getting bogged down by using .childNodes[1].childNodes[0].nodeValue and so on….The childNodes were really pesky little children !! Thanx again !!

Comments are closed.