Web Design for Terminal Browsers | Andros Fenollosa
Skip to content
This is a purely-for-fun exercise: a guide to web design for terminal browsers. Starting from the text browsers people actually use, I am going to pull out a set of rules in case you ever decide to build a site meant to read and look its best in a terminal. It is not an alternative to Gemini, Gopher or a smallweb attempt, but a set of best practices so your site reads well in a terminal browser, and even so you can build Web Apps for the terminal.
Five engines, one test
The first step is to install the five text engines people actually use and feed them the same test pages, isolating one feature at a time.
w3m (0.5.6): the most capable with tables, and it even draws images in terminals that allow it.
lynx (2.9.3): the patriarch, the lowest common denominator since 1992.
links (2.30): fast, with a little bit of CSS.
elinks (0.20.0): the cousin with bigger ambitions, it even has an optional CSS engine.
EWW : the Emacs one.
Now we look for the compatibility crossovers. You test HTML and CSS features and see how each engine interprets them.
The results:
Feature<br>EWW<br>w3m<br>lynx<br>links<br>elinks
JavaScript<br>No<br>No<br>No<br>No<br>No
/ sheets<br>No<br>No<br>No<br>No<br>Partial
display:none inline<br>Hides<br>Shows<br>Shows<br>Hides<br>Shows
display:none by class<br>Shows<br>Shows<br>Shows<br>Shows<br>Shows
inline color<br>Yes (with contrast)<br>Depends on the terminal<br>Depends on the terminal<br>Depends on the terminal<br>Depends on the terminal
text-align<br>No<br>No<br>No<br>No<br>Yes
Data tables<br>Yes<br>Yes<br>Yes (no borders)<br>Yes<br>Yes
colspan / rowspan<br>Yes<br>Yes<br>Flattens<br>Yes<br>Yes
Graphical images<br>Yes<br>In the terminal<br>No<br>No<br>No
alt of a broken image<br>Yes<br>Yes<br>Yes<br>Yes<br>Yes
srcset<br>Yes (picks resolution)<br>alt/src<br>alt/src<br>alt/src<br>alt/src
data: URI in an image<br>Yes<br>alt<br>alt<br>alt<br>alt
GET/POST forms<br>Yes<br>Yes<br>Yes<br>Yes<br>Yes
Collapsible<br>No<br>No<br>No<br>No<br>No
Spacing of , ...<br>No<br>No<br>No<br>No<br>No
Yes<br>Yes<br>Yes<br>Yes<br>Yes
, , , lists<br>Yes<br>Yes<br>Yes<br>Yes<br>Yes
From this we draw some general conclusions:
JavaScript does not exist. In any of them. It is not slow or partial. There simply is no interpreter.
CSS is almost a mirage. Stylesheets, whether or , are ignored in all of them except elinks, which applies a few things like text-align. Four out of five engines do not read your CSS. Design as if it were not there.
display:none is a trap. If you hide something with a class (class="hidden" and .hidden{display:none} in your sheet), all five engines show it. Every one. Because they do not read the sheet: do not hide anything important with CSS. If it should not be seen, do not put it in the HTML.
Images are text. Only EWW (and w3m in some terminals) actually draws the image. In the rest, the image is its alt attribute. All five fall back to alt when the image is broken, and an image with no alt leaves you a [hero] with the file name, or nothing at all. alt is not accessibility for others, it is your content.
does not fold. None of the five make it interactive. The summary and the body always show, one after the other.
HTML5 semantic tags are invisible. article, section, nav, header, footer, main, aside: they are transparent containers. They do not add a single line break. Their value is semantic, not visual.
With that, we can lay down a few design lines and best practices.
8 rules for publishing to the terminal
1. DOM order rules
There is no float, no flex, no grid, no order. Whatever you put first in the HTML comes first on screen. So place the content right after opening the and send the long navigation and the footer to the end. A reader who opens your article does not want to tab through thirty menu links before reaching the first sentence.
2. Mark structure with tags, not styles
Real headings .. for the hierarchy, never a . Lists with /, definitions with . Quotes with , which all of them indent. Code with and . Each engine gives them its own treatment: use them for what they mean.
3. Your page must read with CSS turned off
This is the touchstone. If you disable CSS and your page becomes unreadable, it is not the terminal browser's problem, it is your HTML's problem. Spacing (margin, padding, line-height) does not exist: the separation comes from paragraphs. Structure with real , not with loose .
4. Do not convey information with color alone
A "required field in red" or a "green = correct" evaporate. Inline color is the most fragile thing in the table: it depends on the terminal and its configuration, and in many cases it does not even show. Always pair color with text or a symbol. An "Error:" in front, an asterisk, anything.
5. Tables for data only, never for layout
EWW and w3m draw a surprisingly good ASCII grid, colspan and rowspan included. But a layout table produces an absurd, unreadable grid. Watch the width: if the columns add up to more than the terminal's, the experience degrades. Fewer columns and short cells win.
6. Images with a descriptive alt and srcset
alt is what you see in four out of five engines. Make it a sentence, not an...