A textarea, as much as it looks in HTML like a pair of tags that's capable of having DOM child nodes inside it, can really only have text content attached to it

A textarea, as much as it looks in HTML like a pair of tags that's capable of having DOM child nodes inside it, can really only have text content attached to it in the DOM. In other words, a textarea's innerHTML content, just acts like the `value` attribute of an <input> — being rendered by a special renderer unique to the textarea, rather than by treating the <textarea> as a regular CSS box that "contains" its child nodes. You can't independently address and style a node within the "contents" of the textarea, any more than you could style a node within the label of a <button>. And this should make sense, if you realize that <textarea>, like <button> and a few others, were traditionally not rendered in HTML by the browser's HTML renderer at all, but were instead rendered by calls to the same OS common-controls library that the browser used to render the browser chrome — with CSS properties set on such elements getting translated into attributes set by the browser on the OS graphics-toolkit widget handle. Webkit/Blink no longer do this (and while I think Firefox still does, it only does it under limited circumstances), but the "CSS semantics" of these elements still operate under the assumptions that they're opaque to internal modification, because of browsers that implement rendering of these components by passing control to OS graphics-toolkit rendering for them.