Hacker News Reader

Comment by bdahz | Hacker News Reader

Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs?

An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1].

[1] https://verygoodgraphics.com/, the website is built with its own technology (wasm version).

[2] https://docs.verygoodgraphics.com/specs/overview

[3] https://github.com/verygoodgraphics/vgg_runtime

View on HN

VeryGoodGraphics has no accessibility tree and no results when searching the documentation for “accessibility”, which makes it broadly immoral (or if you want to disagree with that, at least illegal to use it to build production systems in many locations). If you can’t get that right from the start, or even have plans for it, then you’re obsolete.

Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad.

We escaped Flash. We shouldn't clamor to go back.

The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility.

If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?

No? Why shouldn’t apps be accessible?

> However if you take browser as a universal application platform, then accessibility is not necessary, right?

Are you really suggesting that people with disabilities shouldn't be able to use web apps?

Sorry, I was just raising my question. Because in my country most app maker does not care about accessibility. Now I know.

If there is a VGG-native browser then accessibility is not so hard to implement. The awkward problem is that current VeryGoodGraphics is just a canvas node in HTML (using WebAssembly + WebGL). So adding accessibility support will be a nightmare technically.

Lively Kernel was one such idea.

https://youtu.be/gGw09RZjQf8?feature=shared

https://permacomputing.net/smallnet/

Lock Casey Muratori in a room until he designs the right API? He definitely believes the current one is the wrong API :-)

Relevant XKCD: https://xkcd.com/927/

My opinion is that the rendering engine should be WASM specified in a header. This way the site provider can choose whatever engine they want, including possibly not even using HTML.

Yeah - there really is a opportunity now to rethink browsers as just sandboxed rendering windows using WebAssembly + WebGPU.

Could still have typical DOM rendering handled with Webassembly delivered by the web sites (ideally cached). The challenge is though still having standards and accessibility options. That VeryGoodGraphics example allows for no text selection - and doesn't at all handle zooming. Still though it'd be a good bottom up way for a new browser to disrupt Chrome

How would ad blocking work in this world? A browser without ad blocking is useless.

How would ads work in this world? The advertising ecosystem relies on adding a 1-2 line JavaScript blurb to the page, and then the ads are added at display time.

Reply on news.ycombinator.com