I’ve been working on rich text editing ideas for the past month or so, and I have to say, innerText is probably not the solution you’re looking for, for that use-case. Despite what they say about standardization, there are still subtle differences between browsers over how exactly they handle certain elements and styles. The innerText property also does a feeble attempt at representing rich text whitespace, by making table cells tab-separated and adding an extra newline of padding around p elements, which is probably not what you want. Worst of all is that this algorithm relies on layout and styling information like the white-space, display and visibility properties, so it’s likely that it will never be supported in non-browser environments like JSDOM, and even when supported it is likely to cause crushing layout shifts if you’re not careful about when you read it.

If you’re interested in getting the “text” of some DOM, you should know that none of the built-in browser APIs will get you what you want, and moreover you’re gonna want it to be extensible in some ways so that you can, for instance, replace img elements with some equivalent markup, or omit the rendering of off-screen parts of large documents via windowing/virtualization. At the end of the day, there is no canonical representation of some DOM as plain text.