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.

There is nothing wrong with <textarea> it is just sometimes you need more control than you can get from <textarea> in those instances using contenteditable is a perfectly fine solution. Othertimes you realize dropping the feature and sticking to <textarea> is also fine.

As a front end developer I use either under different circumstances. If a feature like marking the portion of text that overflows the allowed length of the input, makes sense for the app, I will grab a contenteditable for the job. If it turns out it is enough to tell users that the text was too long with an error message under the text box, then I will just use a <textarea>, potentially with the Constraint Validation API.

IMO it makes a lot of sense to offer decoration or visual clues to plain text boxes. The original prompt I gave about highlighting is also not an example of rich text as we are not actually changing underlying content.