├── index.html ├── LICENSE └── README.md /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | innerText has been moved to the HTML Standard 4 | 5 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Per CC0, to the extent possible under law, the editors have waived 2 | all copyright and related or neighboring rights to this work. 3 | In addition, as of March 7, 2017, the editors have made 4 | this specification available under the Open Web Foundation Agreement 5 | Version 1.0, which is available at 6 | http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. 7 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # innerText 2 | 3 | This repository historically contained a proposed specification for the DOM `innerText` property, as well as tests. The specification has since moved [into the HTML Standard](https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute), and the tests have moved [to the Web Platform Tests project](https://github.com/w3c/web-platform-tests/tree/master/innerText). 4 | 5 | This repository is now kept for historical reference (via the commit history, issue tracker, and the contents of this README). 6 | 7 | ## History 8 | 9 | `innerText` was introduced by Internet Explorer but never specified in any official document. It was later implemented (incompatibly) by WebKit; this implementation was inherited by Blink. The intent of `innerText`, as it has evolved, seems to be to return the "rendered text" of an element, similar to what browsers produce when equivalent HTML content is copied to the clipboard as plaintext. 10 | 11 | There is no "one true way" to convert HTML, or rich text in general, to plain text. Such conversion can generally be implemented effectively in Javascript with existing DOM APIs. Therefore, there is no need to have this feature in the Web platform, and we might be better off if it was delegated to libraries. However, `innerText` is implemented in popular browsers and is used by many Web sites. Therefore it should be specified. The goal of this repository was to produce a reasonably simple specification that is Web-compatible and that browser vendors are willing to implement. 12 | 13 | ## Compatibility Notes 14 | 15 | ### Setting `innerText` 16 | 17 | The original intent of the `innerText` setter seems to be that setting an HTML element's `innerText` to a string will render that string visually. To that end, both Chrome and Edge (as of October 2015) convert `\n` and `\r` characters to `
` elements. They also both convert a `\r\n` pair to a single `
`. Edge goes further, converting some whitespace characters to ` ` to avoid whitespace trimming and collapsing — but Chrome does not. 18 | 19 | There is already a simple and completely accurate way to have an HTML element render a string as-is: make the element `white-space:pre` and set its `textContent`. Therefore we specified `innerText` to do the simplest thing compatible with what browsers do, i.e. Chrome's behavior. 20 | 21 | ### Getting `innerText` 22 | 23 | The intent here seems to be that getting an element's `innerText` returns its text "as rendered". All browsers seem to have implemented a different set of heuristics for approximating that, typically approximating some subset of CSS processing. 24 | 25 | We can avoid specifying processing rules that duplicate and approximate some subset of CSS by specifying `innerText`'s getter in terms of the rendered text produced by CSS layout of the element. This won't work for elements which have no CSS boxes (e.g. `display:none` elements and elements not in a document), but Webkit/Blink already bail out for those elements and just return their `textContent`, so we followed suit. 26 | 27 | Note that descendant nodes of most replaced elements (e.g. `