horizon-browser

# horizon — a real browser engine for LingOS

`horizon` is LingOS's second web engine: a `no_std` + `alloc`, zero-dependency
HTML/CSS **box-model** layout library, sibling to
[`bring-browser`](../bring-browser). Where `bring` is a `links`/`lynx`-style
text-flow engine (fixed line buffers, no allocation, no real box model),
`horizon` builds an actual DOM tree, cascades CSS onto it, lays it out with
real block/inline boxes, and paints a **pixel display list** — including a
`<canvas>` element with a real 2D drawing surface. It is not a JS engine and
does not pretend to be WebKit/Gecko/Servo; see the roadmap below for what's
honestly in scope today.

The engine never touches a screen itself. Like `bring`, it hands a laid-out
`Page` (a display list of rects/text/canvas/image items, in pixels) to a thin
embedder — LingOS's desktop compositor (`ling-kernel/src/drivers/horizon.rs`)
walks that list with the kernel's existing `framebuffer` + `font8x8`
primitives, the same way `ling-kernel/src/drivers/browser.rs` already does
for `bring`.

## What renders today (v0.1)

- DOM: `html`, `head`, `body`, `div`, `span`, `p`, `h1`–`h6`, `a[href]`,
  `b`/`strong`, `i`/`em`, `br`, `ul`/`ol`/`li`, `img[src]`, `canvas[width][height][id]`,
  `pre`, `title`; `script`/`style` contents parsed for CSS only, never executed
  or rendered as text.
- CSS: inline `style=""` and `<style>` blocks, tag + `.class` + `#id`
  selectors, cascade by specificity + source order. Properties: `display`
  (`block`/`inline`/`none`), `color`, `background-color`, `width`, `height`,
  `margin`, `padding` (single value, uniform on all sides — shorthand
  per-side values are roadmap), `font-weight: bold`, `text-align`.
- Layout: real normal-flow box model. Block boxes stack vertically with
  margin/padding/explicit-or-auto width; inline content (text + inline
  elements) flows and wraps within the content box at the embedder's glyph
  metrics (monospace only — `horizon` takes a `char_w`/`line_h` in pixels,
  same spirit as `bring`'s `cols` parameter, so it stays font-agnostic).
  No floats, no flexbox, no grid, no absolute/relative positioning yet.
- Canvas: `<canvas>` allocates a real `CanvasSurface` (`Vec<u32>` pixel
  buffer) with a 2D drawing API — `fill_rect`, `stroke_rect`, `fill_circle`,
  `line`, `set_pixel`, `clear` — addressable by the embedder or host Rust
  code via `Page::canvas_mut(id)`. **Scripted** canvas (a page's own
  `<script>` calling `getContext("2d")`) is not implemented; there is no JS
  engine yet, so nothing drives the canvas except native code that already
  has a `&mut Page`. This is the same honest limitation `bring` states for
  scripting generally.
- Output: a flat `Vec<DisplayItem>` (`Rect`, `Text`, `Image`, `Canvas`) in
  paint order, plus link/image tables — the embedder walks it once per frame.

## Roadmap, honestly staged

1. **CSS box model completeness** (near): per-side margin/padding/border
   shorthand, `border` painting, `%`-relative widths, `position: relative`.
2. **Proportional text + inline-block** (mid): today's layout assumes a
   monospace glyph grid because that's what LingOS's `font8x8` gives it;
   real font metrics (variable glyph widths, LingOS's `font_unicode` table)
   need layout to measure text instead of counting characters.
3. **Flexbox subset** (mid-far): the single most-requested real-world layout
   primitive; a constrained one-axis flex (`display: flex`, `flex-direction`,
   `justify-content`, no wrapping) before anything fancier.
4. **Scripting** (far): if it lands, a small interpreted subset sharing
   LingOS's in-kernel VM work, the same stance `bring` takes — not a JS
   engine bolted onto a kernel. Until then, `<canvas>` is a real paintable
   surface that only native code can drive, and pages with script-driven
   behavior render their static markup only.

Each stage lands with host tests in this repo (`cargo test`, no kernel
required) before it's wired into `ling-kernel`.