[whatwg] Proposal: Add HTMLElement.innerText

[Mike Wilcox]

Wow, I was just thinking of proposing this myself a few days ago.

In addition to Adam's comments, there is no standard, stable way of *getting* the text from a series of nodes. textContent returns everything, including tabs, white space, and even script content.

BTW, I haven't checked, but I read that Opera's innerText implementation is essentially an alias of textContent.

Mike Wilcox
http://clubajax.org
mike at mikewilcox.net



On Aug 14, 2010, at 5:39 PM, Adam Barth wrote:

> == Use Case ==
> 
> It's common that a web page has a string of untrusted characters
> (e.g., received via cross-site XMLHttpRequest or postMessage) that it
> wishes to display to the user.  The page wants to display the string
> using a simple, secure API.
> 
> == Workarounds ==
> 
> Currently, the path of least resistance is to assign the string to
> HTMLElement.innerHTML.  However, that is insecure because the
> untrusted string can execute script via that API.
> 
> It's possible to display the string securely using the following pattern:
> 
> elmt.appendChild(document.createTextNode(untrusted_string));
> 
> However, that pattern is more cumbersome than "elmt.innerHTML =
> untrusted_string", so developers end up writing insecure code.
> 
> == Proposal ==
> 
> We should expose a property on HTMLElement similar to innerHTML called
> innerText.  When assigning a string to innerText, the string is placed
> in a text node (and is not parsed as HTML).
> 
> == Deployment ==
> 
> HTMLElement.innerText appears to be deployed in Internet Explorer,
> Chrome, Safari, and Opera.  However, the API is missing from Firefox
> and the HTML5 spec.  (Note the existing implementations of the API
> seem to do some work around newline normalization, which we should
> consider when adding the API to the specification.)
> 
> Kind regards,
> Adam