That would be quite an own goal, to invite an extra middleman into the mix. Especially when so many people will go the path of least resistance and use a tech giant product as that middleman.
> Terminal emulators display grids of characters using all sorts of horrifying protocols.
What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.
Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.
I haven't personally implemented one but I'll quote someone who has spent a lot more time on it:
> Many of these implementations are ad-hoc, one-off solutions. They aren't using any shared library or codebase.2 Terminal emulation is a classic problem that appears simple on the surface but is riddled with unexpected complexities and edge cases.3 As a result, most of these implementations are incomplete, buggy, and slow.4 [1]
(I mean, it's possible html/css deserves to be called horrible also but they produce an undeniably superior result)
