Smart TV web browsers were where I first noticed that The Web doesn't work well on any device (an early strength it was promoted on), and how rediculous that was. As such I'm keen to build a better smart TV web browser.
Besides, I'd rather watch entertainment from The Open Web than a bunch of silo'd "streaming services". Especially when those services oppose software freedom by imposing DRM.
I'll design this browser for traditional TV remotes, without using anything flashy like turning it into a (subpar) wiimote. Which some smart TVs are now doing.
I wanted to name it after something from classic TV like Star Trek or The Twilight Zone. But I couldn't find anything distinctive or obscure enough. So I took this name from the spaceship on which WOLF 359 is set. Who might have taken it from the fact that Haephastus is Vulcan's greek name, and Spock from Star Trek is a "vulcan".
Feel free to suggest an alternate name!
Webpages will be rendered near-fullscreen split into "screenfulls" navigated by selecting the inserted header and footer. This header and footer will also communicate:
The playback buttons will read the page aloud using Rhapsode, with other buttons for:
The arrow buttons would navigate between links, <details>,
& form inputs. When you activate a link, the existing page will slide to the
left (in reference to the history UI) slowing to a near step near the end
(to indicate navigate all the way left will provide another back button).
Meanwhile the selected link would enlarge to fullscreen as the referenced page
loads over it (to solidify a connection between them). This animation would
be there both to indicate a new page is loading, and communicate how to use
the browser.
Selecting a form input or (ideally) a link to a self-contained webform would bring up a step-by-step "wizard" for filling in the form & submitting it, including onscreen keyboards, calendars, etc.
When you press menu or blue, the page will zoom out to show:
The arrow buttons would navigate between these pages with menu/select zooming in on that page.
At the root would be a page holding an addressbar & tagged bookmarks. Pressing up and down there would navigate between time-distinct "sessions", whilst navigating further left would allow to select different days.
JavaScript will not be supported, because (amongst other reasons) I cannot allow pages to shift around whilst the user is navigating them & I cannot provide all the events they expect without worsening the UX.
As for CSS, the question is less what should I support but rather how hard
it is & visually damaging they are. In terms of visual damage, the CSS
position property, as it allows one element to obscure another.
Print (for pagination) and voice (for VCR buttons) properties would be
supported.
CSS Animations and grids will be supported, in part because they'd help me implement page transitions & tables.
Some variation of XHTML2-style links would be supported, with an intent to support a majority of HTML5 markup. I'm not yet sure how much of HTML5 forms I will support.
If people are interested in exploring practical uses for them, I would be interested in exploring HTML extensions like:
Haphaestus could be split into the following components:
Before it can be rendered, text must be assigned a position & size onscreen. I'm interested in writing this (partially) myself with help from libraries like Harfbuzz, libICU, & FreeType so I'm not constrained in how much CSS I can support. Though I have been learning some interesting Pango & FontConfig tricks from Weasyprint.
I'll be more than happy to fix any resulting bugs in how different written languages are rendered.
I'm currently thinking this should be largely implemented in GLSL, handed a laid-out & flattened style tree. That would reduce performance concerns elsewhere & integrate more easily into Haskell.
I'm open to CPU-based rendering, and I reckon FreeType should be used to make sure text is rendered correctly accross all languages.
Once the lines have been split & the page has been laid out, the links need to be reassembled into a 2D menu that can be navigated using the arrow keys. Linesplitting & varying link density may make this relatively tricky, in that we can't just ask the layout algorithm.
The basic problem is to find the closest element above, below, left, & right. This may be most efficiently solved using a sweep-line algorithm.
To handle webforms, this browser would need to have them rendered to menus. Which the rest of it allows devs to express in standard HTML+CSS.
As such this component can be implemented as a self-hosted serverside webapp, no restrictions on implementation language.
There'd be two parts to this: tree-style history implemented as it's own mode, and a homepage holding bookmarks.
Rhapsode provides HURL for resolving URLs & Haskell Stylist for applying CSS to a webpage. These components can be reused.
The following projects already exist, and could provide useful components for Rhapsode:
Gaming controllers are designed to be more interactive than TV remotes, and adds a joystick that would be useful for scrolling webpages. Plus 8pen shows how that joystick can be used to quickly type text.
The more constrained input from TV remotes interest me more, but it could be worth porting Haphaestus to gaming remotes to take full advantage of that joystick.