Font with Built-In Syntax Highlighting

Overall reaction

  • Many commenters are delighted by the creativity; repeatedly described as “wild”, “ridiculously smart”, and a “wonderful abuse” of OpenType.
  • Others see it as a “horrible hack” or “atrocious” in principle, but still impressive as an experiment.
  • Several predict niche but real adoption (e.g., blogs, CMS textareas, presentations), and joke about big tools rushing to add it.

How it works and expressiveness

  • Uses OpenType contextual alternates (calt) plus color glyph tables (COLR/CPAL) to recolor glyphs based on surrounding characters.
  • Clarification that colr is not an OpenType layout feature, and calt is usually on by default; the CSS font-feature-settings line is mostly unnecessary.
  • Base rule system is simple: match single characters or character classes in context.
  • Multiple commenters argue it’s more powerful than the article suggests: you can effectively drag a finite-state machine along via chained substitutions (including reverse chains), allowing regular-language–level logic.
  • Concrete examples show how to implement quoted-string highlighting and escaping purely with substitution rules.

Performance and behavior

  • One informal benchmark on ~20k lines of CSS: enabling calt made a font-size change reflow take ~1.6s vs ~100ms with calt off.
  • Large documents feel laggy when layout depends on heavy shaping, since it affects scrolling, resizing, and selection.
  • Some browser bugs/quirks noted (partial highlighting in Chromium when typing, Safari regressions for COLR support in certain versions).

Tooling and automation

  • Font editors mentioned: Glyphs (with Python scripting), FontForge (harder UI), emerging browser-based tools; any editor that allows manual OpenType feature code can, in principle, support this.
  • Ideas to:
    • Generate fonts automatically from grammars (e.g., TextMate, tree-sitter) and color themes.
    • Embed fonts via base64 @font-face.
    • Build an online generator for “syntax-highlighted fonts”; blocked somewhat by tooling (e.g., opentype.js missing calt support).

Use cases, strengths, and limitations

  • Big advantages: no JS, no DOM span explosion, works in plain <textarea>, can be used wherever only a font is configurable (e.g., Notepad, terminals in future, some PDFs/editors with OpenType support).
  • CSS @font-palette-values and font-palette (with override-colors) allow recoloring without regenerating the font, at least in supporting browsers.
  • Major limitations:
    • Not language-aware enough for full IDE-grade highlighting: keywords inside plain prose, strings, or embedded languages can be miscolored.
    • No bracket-depth coloring; hard to robustly handle multi-line comments/strings given limited context and partial repaints.
    • Needs different fonts (or variants) per language and, in some environments, per background/theme.
  • Some see it as neat but impractical compared to traditional highlighters or CSS Highlight API; others argue it’s perfect for static publishing where any JS is undesirable.

Security and broader implications

  • Several note this illustrates why fonts are a real attack surface: they can embed complex behavior; past font-related exploits are cited.
  • One commenter refuses to load the demo out of concern about malicious ligature logic.
  • The project prompts broader appreciation of how overpowered font technology is (e.g., prior work like games or even LLMs embedded in fonts).