Hush is a for-fun, toy browser. I’m playing around with alternative rendering/interactions, so not trying to match the rendering of Firefox/Chrome/Ladybird. I hope to have multiple different “modes” for viewing (links all at the bottom, links in a sidebar) and allow the user more control over what is actually downloaded or run.
The goal of Hush is to quiet down the web. Inline hyperlinks, flashy images, and other (ab)uses of hypertext make it hard to read online content without constant interruption. Hush aims to provide an alternative way of viewing online content where you have control over what is displayed and when. Images are loaded when you want them.
The user also gets control over fonts, background colors, etc. Some might say that this cramps the creatives style of the other. There may be some truth to this, but the computer owner and user should also get a say in how their computer is used.
Current state:
Hush can load a page, parse most common tags, and load png/jpeg images (SVGs are partially supported, pending upstream changes/fork)
Basic navigation in place: Back, reload, link clicking
Tags supported: html, body, header, footer, div, p, img, ul, ol, li, table, thead, tbody, td, tr, a, br
Oops, forgot to add my fork of superhtml to the build.zig.zon file. I’ve had to make a few changes and am trying to upstream them. I just pushed up a change to use my fork.
Thank you for pulling the repo and giving it a go!
Yes, I do plan to add Javascript support, most likely using Kiesel. But that is not a priority right now.
I have a couple ideas around scripts. It might be cool to support another language like lua or something to add some diversity to web languages. I also want to allow users to approve/block scripts from running. Not just wholesale (turn of all javascript), but allow selecting ones that you are okay with running.
As a general comment wrt SuperHTML, I wrote it exclusively with the cli tool / templating language usecase in mind, meaning that if you ever want to make serious use of it in a browser, chances are that it will fall short, especially when it comes to the parser (the tokenizer is mostly fine).
Anyway, just wanted to manage people’s expectations, for a for-fun browser it does seem a reasonable idea to use it so you can focus on the more interesting aspects of making a browser.
It doesn’t implement the spec-defined error recovery procedure and it doesn’t support evaluating JS code that might modify the source code, both things that are necessary if you want to implement a fully spec-compliant browser.
Since superhtml was meant to run as part of tooling, it doesn’t concern itself with any runtime DOM requirement.
I appreciate the explanation/warning. Without SuperHTML, I probably wouldn’t have started this. It helped me get started without worrying about html parsing.
I have been designing Hush to separate the html AST from the DOM/render representation. So not having a runtime DOM built in is fine. Same with JS code. It should operate on the DOM/render tree.
I’ll have to put this on my list of things to look into. Thanks for your input!
really cool idea. i was thinking of something similar to this about a decade ago using godot 2.1 to make some kind of dumb web viewer. like a minimalistic way to view websites (think of a temu version of a winforms webbrowser control). but with godot’s native ui elements.
your project seems far better and more extensive. the way the modern web is becoming is absolutely bananas. +1. i will create an account on there to star it