Earlier quoted context omitted.
I like the idea behind your wrapper but I think you’re mistaken regarding hidden. Things are hidden from browsers for a lot of reasons but a text browser should probably safely ignore them all as content and presentation are different.
I mean for example one of the big problems Browsh has is not rendering text that web developers have hidden in the DOM to be displayed on some kind of mouse interaction. So Browsh has to ask JS to query the `display: hidden`, `z-index`, etc values to ensure that it doesn't render text that is not intended to be displayed until after an interaction.
You can argue that using the CSS display property is a bad hack around the poor performance of adding/removing DOM elements, but the general problem of trying to automatically adapt a GUI application to terminal display does not change (having the GUI be emulated in HTML that is meant to be displayed in the GUI of the web browser just adds a layer of indirection, difficulty, and inefficiency). On the other hand, web pages that are really hypertext documents wrapped in useless and inaccessible JavaScript and CSS can have all of the event handlers and CSS properties ignored, and become legible again. This is something that text browsers do well, and why text browsers continue to be relevant today.