[whatwg] Proposal: Add HTMLElement.innerText
Mike Wilcox
mike at mikewilcox.net
Sat Aug 14 17:03:30 PDT 2010
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
More information about the whatwg
mailing list