Why rectangles?

The mental model behind m0saic

// what is m0

m0 is a layout language. A single string describes how rectangles subdivide inside a canvas — no pixels, no coordinates, just structure.

2(F,3[F,F,F])→

// two columns, left gets 70%
10(>,>,>,>,>,>,F,>,>,F)

// three equal rows
3[F,F,F]

// nested: 2 columns, right split into 3 rows
2(F,3[F,F,F])

// gap between two tiles
5(F,>,>,-,F)

// overlay: content layered on top
2(F,F){F}

The language is small. () split columns, [] split rows. F claims a tile, > donates space forward, - marks empty space, and {} layers content on top. That’s the entire surface.

// why not css?

CSS is a layout solution for the browser. Flexbox, Grid, and absolute positioning solve responsive, interactive UI. m0 solves a different problem.

No floating point

m0 uses only integer arithmetic. A 3-column split of 1920px produces columns of exactly 640, 640, 640 — not 640.000001. When pixels don’t divide evenly, remainders are distributed outside-in to keep the layout balanced. No rounding errors, no sub-pixel drift.

String-native

Layouts are plain strings. Concatenate, template, store, diff, and version them like any other text. Every language already has the tools — m0 piggybacks on string composition.

Infinitely composable

Any tile F can be replaced with any valid m0 expression — one character or a million. 2(F,F) becomes 2(3[F,F,F],F) by swapping one token. No special API — just strings.

Cross-platform

The same m0 string produces the same pixel-exact rectangles in JavaScript, Python, Rust, or a shell script. The layout is portable, the renderer is local.

Deterministic

Same string + same resolution = same rectangles. No layout engine quirks, no browser differences, no reflow. Parse it today, parse it in five years — identical output.

Low implementation bar

Any language with integer arithmetic and string concatenation can build a valid m0 library. No graphics stack, no layout engine, no dependencies — and it immediately reads and writes every .m0 file out there.

The trade-off: m0 is not as responsive. Layouts are designed for a specific resolution, or constructed programmatically. Determinism and cross-platform consistency matter more than dynamic reflow when your output is a rendered frame.

// throw away the timeline

Traditional video tools organize content on a timeline. Layers stack vertically, clips stretch horizontally. Time is the primary axis.

TIMELINE

→

GEOMETRY

That works for editing. But for generating video programmatically — bar charts, dashboards, data visualizations, social media templates — time is the wrong abstraction. The hard part isn’t sequencing clips. It’s placing content in space.

m0saic uses geometry as its base. m0 is the geometry solution.

Instead of a timeline, you describe a layout. Each rectangle becomes a content slot. Fill the slots with images, videos, text, or colors. Frames are composited onto a final canvas based on the m0 geometry. The engine renders the output using ffmpeg.

Time is just another property of how that static rectangle behaves — enable at 2s, fade in over 500ms, hold for 3s, fade out. The rectangle itself is absolute. Everything else is configuration.

Traditional video scales horizontally — more clips on a longer timeline. m0saic scales vertically through composition. A dashboard is a layout that nests calls to opinionated templates (bar-graph, pie-chart, etc.), each of which returns its own m0 geometry and sources to fill those rectangles. Complexity grows through depth, not duration.

// rectangles → video

Here’s a real example. The @m0saic/hero/bar-graph/v1 template takes data and renders an animated bar chart. One CLI call:

$ m0saic make @m0saic/hero/bar-graph/v1 \
  -w 1920 -h 1080 \
  --props '{"values": [72, 45, 88, 31, 66]}' \
  -o bar_chart.mp4

1920 × 1080... chars

Same template, same data, different resolution. The template maps data to geometry. The geometry maps to pixels. ffmpeg renders the output. No GUI, no timeline, no manual placement.

// where this fits

m0saic is not a video editor. It’s a video compiler.

Batch rendering

Generate 1,000 variations of a template with different data. Each run is a CLI call with different props.

Cron jobs

Render a daily dashboard video from live data. Schedule it, forget it.

CI/CD pipelines

Generate preview videos on every commit, deploy video assets alongside code.

Cross-platform output

Same template renders 16:9 for desktop, 9:16 for mobile, 1:1 for social. The layout adapts, the data stays the same.

Traditional editors are interactive tools for human creativity. m0saic is a deterministic tool for programmatic output. They serve different purposes.

// the model

m0 string→rectangles→template→CLI→ffmpeg→output

→A layout string divides a frame into rectangles.

→Each rectangle is a content slot with exact pixel bounds.

→A template maps data to slots and dynamically generates its own m0 geometry from input props.

→The CLI compiles the template into an ffmpeg command graphset.

→ffmpeg renders the final output.

That’s why rectangles. They’re the atom of visual composition — simple enough to reason about, powerful enough to express any grid-based layout, and deterministic enough to compile.