Markus

GitHub-flavored Markdown, plus a small vocabulary for layout intent.

Markdown for layout intent

GitHub-flavored Markdown with a small, semantic vocabulary for layout.

Markus keeps GitHub Flavored Markdown as the content language, then adds a handful of colon-fenced directives for the things Markdown was never meant to say: this is a pull quote, these are peer cards, these two ideas belong beside each other.

The source stays diffable. The renderer decides whether that pairing becomes two columns, a stacked phone layout, or a print spread.

Encode intent in the document. Leave grid tracks, type ramps, and hover states to the theme.

Markus design principle

A vocabulary small enough to remember

Pull quote

An editorial quotation with optional attribution, tone, and alignment.

Card grid

Peer ideas that should read as a set, not a numbered list pretending to be a layout.

Two-up

A conceptual pairing: contrast, before/after, claim and caveat.

What belongs in the source

  • The kind of block you mean
  • A short, validated attribute set
  • Nested Markdown, including other directives
  • Document metadata in YAML front matter

What belongs in the theme

  • Column counts that collapse on small screens
  • Typography and color
  • Print, EPUB, or email fallbacks
  • Component-level accessibility rules

Ratios on a three-column track

two-up ratios count parts across three columns: 2:1 is two parts plus one; 1:2 is one plus two. Blocks outside two-up span the full width.

Primary (2 parts)

The narrative, claim, or longer explanation belongs in the wider column.

Aside (1 part)

Metadata, a caveat, or a short counterpoint.

Lead (1 part)

A label, qualifier, or setup line.

Body (2 parts)

Material that should dominate when the second column carries the weight.

Full width (all three columns)

Outside two-up, ordinary blocks span the entire track. Inside a card-grid, set span=full on a card to do the same.

Metrics as first-class facts

Leaf directives cover facts that should be extractable later — not just styled.

Language version
0.1.0
Directive vocabulary
15blocks+15
Markdown baseline
GFM
Pipeline from Markus source through a validated AST to semantic HTML
Parse, validate, then render. Never regex-replace a directive after the fact. · Markus 0.1

Structured procedures

  1. 1. Encode intent in source

    Author content in GFM, wrapping layouts in colon-fenced directives.

  2. 2. Validate against strict schemas

    Markus checks directives and attributes at compile time, rejecting rogue CSS.

  3. 3. Render accessible HTML

    Output semantic markup ready for static hosting, responsive themes, or print.

Multi-platform instructions

Install with Homebrew or pip:

brew install anthus-markus

Install using pip:

pip install anthus-markus

Install via PowerShell:

pip install anthus-markus

Project timeline

  1. Initial Concept

    Markus originated as a strict semantic layer for technical publishing.

  2. Core AST & Validation

    Implemented the markdown-it directive parser, Pydantic attribute validation, and early theme support.

  3. Rich Directives & Themes

    Added tabs, step lists, timelines, and 20+ accessible color palettes.

Media walkthrough

Why not raw HTML?

Raw HTML is a compatibility hatch, not the authoring API. It names CSS classes, invites sanitizer fights, and cannot tell a renderer whether three boxes are a comparison, a feature set, or leftover layout. Markus keeps a registry: unknown names fail in CI instead of silently becoming untyped markup.