v0.1 · Draft Object Framework · Reference

Containers

A container is any region a surface reserves to be filled. This reference sets out the states a container resolves to and the order it resolves them in — then separates three things that all sound alike: Build mode (the editing view), Draft (a content status), and Publishing states (the site version driven by delivery phase).

Object: ContainerRenders via: Graphics Engine · theme fillDefines: Fill states · Build mode · Publishing states
01

Fill states

A container resolves to one of four states.

FirstImageAn actual image. Either an uploaded crop, or one requested from the Graphics Engine in real time — e.g. a Meta Image or an Email header.
Theme
ElseTheme fillA colour or gradient derived from the client theme. The graceful live default when no image is set.
⛶
Build mode onlySchematicA wireframe and spec for the slot. Shown only while editing — never on a live surface.
—
OtherwiseEmptyNo container instantiated. Renders nothing and reserves no space.
02

The resolution rule

How a container picks its state A live render resolves image → theme fill. If an image is set it wins; otherwise the container shows the theme fill — never a blank or a checkerboard. The schematic appears only in Build mode; it is replaced by image-or-theme the moment the page is viewed live. Empty is not a visible state — it means the container was never placed.
Notes
  • Stating the states as an order, not four parallel options, answers "what shows when nothing was uploaded but the page is live?" — the theme fill.
  • An image isn't always a stored file. It may be requested from the Graphics Engine at render time and baked from context — a Meta Image from page metadata, or an Email header. Either way it resolves as the image state.
  • The schematic is the only state Build mode introduces. Everything else is what a viewer sees.
03

Build mode

Build mode is the editing view. It is the only thing that exposes the schematic state — and it is not the same as Draft.

View Build mode a property of the view — "am I editing this now?" How a surface renders while you're working on it. Turns on the schematic state so you can see and fill each container. Independent of whether the page is published.
Status Draft a property of the content — "is this ready?" A point in the content lifecycle — draft vs scheduled, live, archived. About visibility, not editing. A draft previewed still resolves image → theme fill; it shows no schematics.
They are orthogonal You can be in Build mode on a published page (editing something already live), and a Draft page previewed is not in Build mode (it renders like any live page). The clean test: only Build mode makes the schematic appear. Draft never does.
Notes
  • Conflating the two would break the resolution rule — schematics would leak into draft previews, which should render image-or-theme like any viewer.
  • Build mode is where a designer reviews, adds, and edits container contents. The full workflow lives in the Containers & Artwork reference.
04

Publishing states

A third, separate axis: a single event site renders as different versions across the event lifecycle.

Three axes, three questions The three concepts on this page all sound like "states" but answer different questions. Build mode asks "am I editing?" (the view). Draft asks "is it ready?" (the content lifecycle). Publishing states ask "which version of the site is showing?" (the delivered surface) — and that is driven by the event's delivery phase. The same published site presents a different face depending where the event is in its lifecycle.
Pre-eventDrives registrationThe build-up face. Sells the event and converts visitors to registrants.
LiveDrives engagementThe in-progress face. Gets people into the content as it happens.
Replay / postSignposts discoveryThe after face. Guides people to find and watch the recorded content.
Notes
  • Publishing states are delivery phase made visible on the event site — they express the existing phase framework, they don't redefine it. "Publishing states" is a working name.
  • Open — relationship to fill states. A publishing state may drive a container to resolve to different artwork per phase (a pre-event header vs a replay header). If so it sits above the resolution rule as an input, not as a new state — the four fill states are unchanged. To confirm.
  • All three axes are independent: a page can be in Build mode, while Draft, on a site whose publishing state is Pre-event.
WDS · Container Fill States — Reference v0.1 (Draft)
The four fill states, the resolution rule, and three orthogonal axes — Build mode, Draft, and Publishing states. Folded onto the WDS References shell from the v0.1 draft. The Artwork format suite and the full Graphics Engine relationship are covered in the Containers & Artwork reference; publishing states express the delivery-phase framework. Colour inherits the Master Colour Palette. Draft — not yet canonical.