Type: Article

Changes to how this Type behaves are requested through a GitHub Issue and implemented, together with this reference page, through the repository's normal workflow. See /_docs/posts for how Post Types and Content Types work in general, and docs/Internal/type-doc-templates.md for the Post Type Doc template this file follows.

A written piece hosted on the site. Unlike a simple cover-and-body write-up, an Article can hold any number of content elements — several images, several text blocks, links, contact entries, videos, audio clips, downloadable attachments, geospatial entries, and timeline entries — each with its own role and rank (see /_docs/posts). That's what lets a longer piece mix in extra photos, an aside, a voice note, a reference document, a couple of reference links, or a short chronology without needing a different Type.

Schema

Slots:
- cover       : image      | optional | single
- body        : text       | optional | single
- brief       : text       | optional | single
- images      : image      | optional | repeatable
- texts       : text       | optional | repeatable
- links       : link       | optional | repeatable
- contacts    : contact    | optional | repeatable
- videos      : video      | optional | repeatable
- geospatials : geospatial | optional | repeatable
- timelines   : timeline   | optional | repeatable
- audios      : audio      | optional | repeatable
- attachments : attachment | optional | repeatable

cover, body, and brief are named explicitly above (rather than folded into the generic images/texts wildcard rows) specifically so the admin editor can read this file and know they're Article's standard roles — see /_docs/posts. body and brief are given special meaning by the display logic; cover is the listing thumbnail and a full-page sidebar thumbnail, but never shown inline in the body unless explicitly referenced — everything else is just "more content," shown in addition to body/brief, not instead of them:

• cover (image) — the thumbnail in listings, and an "Additional Information" sidebar thumbnail on the full page too, same as any other image. It's never shown inline in the body automatically — if the admin's own body text explicitly references it (e.g. {{cover}}), it renders inline at exactly that position instead of the sidebar, the same as any other referenced image.
• body (text) — the article's main text, shown first on the full page and used for the excerpt in listings.
• brief (text) — an explicit, optional short introduction shown between the metadata line and body — never synthesized or derived from body when absent (leaving it blank shows nothing there, not an empty container). Rendered as real Markdown, the same as body — content references resolve normally. brief is also preferred over a derived body excerpt in listings when present — see Summary below.

Any other element — additional images, additional text blocks, links, contact entries, videos, audio clips, attachments, geospatial entries, or timeline entries, under whatever role fits — is placed after body according to the placement rules below, never simply appended in one undifferentiated block.

Content placement (Full rendering)

Every Content Element the Article holds, beyond body/brief, is placed into exactly one of two groupings — never both (an element explicitly referenced inline is never also duplicated into Additional Information; Image is the one documented exception, see below). cover is not a special case here — it's placed by the same rules as any other Image.

1. Referenced inline — any element the body (or brief, or any other Text the Article holds) explicitly addresses via a content reference ({{role}}, {{kind:reference}}, {{map:role}}, {{footnote:n}}, …) renders exactly at that referenced position, and nowhere else. This includes cover — a {{cover}} reference is the only way it ever appears inline in the body.
2. Additional Information — everything else, in one shared container with one heading, grouped by Content Type in this fixed order (empty groups are omitted): Media (Image/Video/Audio combined), Attachments, Links, Contacts, Geospatial, Timelines. Within each group, elements are ordered by Rank, then by stable (insertion) order within a shared Rank — never re-sorted by kind name or alphabetically. Text/Markdown and Free-form HTML are never shown here at all, in any form — a non-inline Text is only ever reachable through its own standalone page. Images and Contacts are the two documented duplication exceptions: every Image on the resolved Version appears in the Media group regardless of whether it's also cover or inline-referenced elsewhere, and every Contact appears in the Contacts group even when also referenced inline — every other kind, Video/Audio included, still follows the default "shown once" rule.

An Image group renders as a compact mini-gallery grid (thumbnails only — no caption/byline beside it there; its full caption is only ever shown where it's referenced inline, or in the fullscreen viewer). A Link group card reuses the exact same live/archive-fallback state Link presentation already computes. A Geospatial group card is a real, live mini-map, reusing the same fullscreen/detail interaction a {{map:role}} inline reference already gets. A Text group item shows a bounded preview plus a link to its own standalone page for the full content.

At a ~800px breakpoint, and for print/PDF/no-JavaScript output, the desktop-sidebar placement (below) collapses and Additional Information simply follows the body in normal document flow — the same underlying single container either way, so there's exactly one linear reading order everywhere that isn't the two-column desktop view. This shared container (and its fixed group order) is the same one every other Post Type's Full rendering now uses for its own supplementary content — see docs/Internal/architecture.md.

Rendering contracts

Summary (in a list of posts)

Title, an excerpt (with any content-reference syntax already removed) preferring the explicit brief when present, otherwise derived from body, published date. The info line and title always span the card's full width, on their own rows. When cover is present: below the title, the card splits into a 40%-width Cover image beside the excerpt, alternating left/right by the Post's position in the currently visible, already-paginated/filtered list (Category and Tag list views both use this same shared card); on narrow screens the Cover sits above the excerpt at full width instead, still below the full-width title. The excerpt is truncated at a word boundary (never mid-word) to roughly five lines on larger screens, four on narrower ones. Aspect ratio is always preserved and the Cover is never enlarged past its own intrinsic size. A Post with no cover keeps the plain text-only card, with no reserved empty media area.

Full (its own page)

Domain/site identity (rendered by the site chrome, not this Type), then in order: the Post title (<h1>), a compact metadata line, the optional brief, the complete body text (with any inline content references, including a {{cover}} reference to the Cover image itself, resolved at their referenced position) beside an "Additional Information" container when eligible content exists (desktop), or followed by it (narrow/print/no-JS). The cover image itself is never shown inline in the body automatically — only via an explicit {{cover}} reference in body, same as any other image — but it does appear in the Additional Information Media group like any other image, whether or not it's also inline-referenced (Image's documented duplication exception).

Metadata line: Published · Updated · Original · History, each item omitted when it doesn't apply, with a separator only ever rendered between two already-visible items — never a leading, trailing, or doubled one. Published shows the Post's own publish date (or "Not published," admin-preview-only, for a PrePub Post that's never actually gone live). Updated shows only when its calendar day differs from Published's — a same-day edit isn't worth a second date. History links to the Post's Metadata page — the one consolidated entry point for metadata, Versions/history, and Content Element inspection, replacing the earlier separate Version-number and Metadata links. Original shows only when the language you're viewing differs from the Version's own original language — "Original: DA, AI Translated," for example, where the language code itself is the control: selecting it switches your language preference to the original and does a full page reload (the same operation as the top-right language selector, never a local partial swap). An "Author" item has no backing field anywhere in this data model yet — it's simply never rendered until one exists, not a bug.

Page regions (Full rendering)

• Header — the Hidden/PrePub/Private banner (if applicable), the title, the metadata line, a row of Tag links (if the Version has any — see /_docs/categories's "Tags"), and the optional brief.
• Introduction — the body text, beside the Additional Information container (desktop, when eligible content exists).
• Supplementary — the Additional Information container itself, marked data-region="supplementary" regardless of whether it's rendered beside or after the body — see "Content placement" above.
• Footer — not currently used by Article.

Responsive order: Header, Introduction (body), Supplementary (Additional Information) — the visual column split only exists ≥800px; the underlying document order is identical at every width, so a screen reader, no-JavaScript visitor, printed page, and generated PDF all see the same single, linear order without any separate reordering logic.

Public metadata exposure

Title, type, Stage, Category, published/updated timestamps, Version ordinal, Tags (as JSON-LD keywords), and every Content Element the Article holds (current Version only, unless the JSON-LD history/archive export is used — see /_docs/posts's Metadata page section) are all exposed via the Metadata page and JSON-LD export. The native JSON export (/_docs/json-import) additionally carries full Version history and every historical Content Element.

Admin editor

Every Content Element section is available here, same as every Type. cover, body, and brief are Article's standard roles — cover is the listing thumbnail, body puts that text in the featured position at the top of the full page, brief is an optional short introduction shown just above it; anything else you add is still saved and shown, just placed into the "Additional Information" container depending on its kind (see "Content placement" above). Any element, including cover itself, can also be referenced inline in the body text via content references, e.g. {{role}} or {{link:role}} — a referenced element always renders at that position instead of (or, for an Image, in addition to) Additional Information, and an inline reference is the only way cover ever appears in the body text itself.