w3m

Batch 8 (readers / browsers / hierarchical-navigation TUIs).

What it is

w3m (“a pager with WWW capability”) is a long-lived C text-mode web browser whose distinguishing trait is that it renders structured HTML — tables, frames, and forms — into laid-out terminal text, where most early text browsers flattened everything. Its repo structure maps to its capabilities: html.c (parse), frame.c (frame layout), form.c (form fields), libwc/ (per-character display-width handling — essential when wrapping mixed-width content into fixed columns), and w3mimg/ (an inline-image module that draws actual bitmaps over the terminal via a separate image-display backend). It’s navigable by keyboard or mouse, supports tabbed browsing and right-click menus, and runs in either a colored or a monochrome display mode. It doubles as a terminal pager and integrates with Emacs.

Deckline-relevance

• Table rendering into a fixed-width grid. w3m’s headline capability — turning an HTML <table> into an aligned, box-drawn text table — is exactly the problem KN-86 faces whenever a cart or the runtime needs to present tabular data (a leaderboard, an inventory, a phase-status matrix) inside the 80×23 content area. w3m’s table layout engine (column-width inference, cell wrapping, border drawing) is the reference algorithm. The libwc character-width handling is the subtle-but-critical piece: any KN-86 table renderer must account for glyph cell width to keep columns aligned — and KN-86’s grid is uniform 12×24 cells, which simplifies this versus w3m’s variable-width terminal case.
• Frame layout = multi-pane composition. w3m lays out HTML frames as distinct regions of the screen. KN-86’s SPLIT display mode and any multi-pane cart screen (list pane + detail pane, à la the readers in this batch) is the same compositional problem; w3m is a reference for partitioning a fixed grid into independent scrollable regions.
• Form handling in a text grid. form.c renders HTML inputs (text fields, checkboxes, selects) as in-line, keyboard-navigable text widgets. KN-86 intake/config surfaces (operator handle entry, SYS-tab settings, cart configuration) need the same: text fields, toggles, and selects drawn as glyphs and driven entirely by keyboard. w3m’s form-widget set is a catalog of the primitives.
• Inline-image protocol concept (w3mimg). w3m’s image support is out-of-band — a separate backend draws bitmaps positioned over the character grid, rather than encoding the image into characters. This is the alternative to the half-block/braille pixel-rendering approach (see browsh, mapscii): a true image overlay. For KN-86 the on-device display is the 80×25/960×600 logical framebuffer in BITMAP mode (per Canonical Hardware Specification), so KN-86’s “inline image” is native framebuffer blitting in BITMAP/SPLIT mode — conceptually w3mimg’s out-of-band overlay, but rendered into KN-86’s own monochrome framebuffer rather than a separate backend.
• Pager duality. w3m being both a browser and a general pager is the right framing for KN-86’s reader-mode surface: one pager engine serves both cart-supplied long-form content and runtime text (logs, lore, message bodies). Build the pager once; point many content sources at it.

Single-color adaptation

w3m ships a first-class monochrome display mode — direct evidence the entire HTML-rendering model survives single-color. Adaptations for amber-on-black:

• Tables via CP437 box-drawing, never color. Borders, header separators, and column rules all come from box-drawing glyphs (┌ ┬ ┐ ├ ┼ ┤ └ ┴ ┘ │ ─). A header row distinguishes itself by inversion (black-on-amber) rather than a tint. This is already KN-86’s native idiom.
• Links/emphasis via glyph markers + inversion. Where colored w3m underlines or tints links, monochrome KN-86 uses inversion for the focused link and numbered [1]-style markers for selectable links (consistent with hackernews-TUI).
• Form widgets as glyph chrome. Checkboxes render [X]/[ ], radios (•)/( ), text fields as inverted/underlined spans, selects as ‹ value › — all character-and-inversion, no color.
• Image overlay vs. character-rendering split. w3mimg’s out-of-band-overlay model maps to KN-86’s BITMAP/SPLIT framebuffer path; the character-rendering alternative (encode the image into glyphs) is covered by browsh (half-block) and mapscii (braille). KN-86 has both options — native framebuffer blit for true pixels, or glyph-encoding for cases where content must stay on the 80×25 text plane. This entry anchors the former.

Notes

• Not a code dependency — w3m is GPL-era C with a deep, terminal-specific codebase. The value is the table/frame/form rendering algorithms and the inline-image-as-overlay concept, studied as reference.
• Cross-link browsh and mapscii — the two character-encoding pixel-render approaches; w3m anchors the contrasting true-overlay approach. Together the three cover the full space of “show a picture in a text UI.”
• Cross-link newsboat — newsboat’s built-in HTML-to-text renderer is the lighter-weight sibling of w3m’s; w3m is the heavyweight reference (tables/frames), newsboat the pragmatic minimum.
• Cross-link ascii-effects.md — the project-wide character-rendering spec that the browsh/mapscii encoding path feeds into.