# 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 (`

`), 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.