Wow I had never heard of element()!
Along similar lines, HyperCard had a lockScreen flag that would stop sending draw commands to the screen, and instead buffer them internally, so that the screen would update once drawing was finished. It's such a powerful abstraction that much of the hand-waving we do today to avoid redraw would just go away, including nearly all of the effort that goes into building single-page applications (SPAs), because their functionality can be simulated by simply locking the screen and fetching new HTML from the server as a dumb terminal so the loading bar doesn't animate:
https://www.hypercard.center/HyperTalkReference/lockScreen
To a first-order approximation, all apps/libraries/frameworks are missing critical functionality like this. The most common design mistake is to provide a setter without a getter, or vice versa. Another one is for a console app to provide a config file setting, with no way to override that as a shell argument to the executable. There are dozens, if not hundreds of these common anti-patterns, so statistically the odds of any piece of software having any of one of them can be considered to be 100%.
So in this case, most "modern" browsers provide a way to render the screen image from an HTML description, but no way to retrieve that image. The canvas element is a band-aid over these original design mistakes. A proper DOM implementation would look like iframes (windows) all the way down, where the contents could be specified from url, attributes, html, vectors/buffers or code. Each would have its own sandbox attributes defaulting to full isolation, so could be treated as its own browser, then their data dependencies could be piped together, a bit like unix executables. Mashups/portals/aggregators would be so easy to build that kids would be doing it.
It's a serious enough problem that honestly I don't really think in terms of HTML/CSS/Javascript anymore. I work in tables mentally, then let the designers transpile that description to CSS. And the real work of building the rich interactions available in desktop programming simply can't be done without massive yak shaving. This was also a problem in OpenGL before better access to render buffers and shaders went mainstream.
IMHO this all started when Netscape became a private enterprise from its Mosaic roots, then was exacerbated when Microsoft monopolized the browser market for so many years, then cemented when Firefox and Chrome endorsed the status quo. The only way out now would probably be to formally build a programmer's browser from scratch with hard security constraints around the core element's external communication, then emulate the current HTML/CSS/Javascript experience we're used to. Sort of like Qt, Postscript, etc. Which of course will never happen, so it's hard to see the positive in discussing these foundational decisions when there's nothing any of us can do to fix them in any reasonable amount of time/money/effort.