Skip to content

[Tracking] Everyday content primitives roadmap #3

Description

@Vonng

Purpose

Track the implementation of OINK's everyday content primitives: small, high-frequency building blocks for engineering documentation that remain semantic, responsive, accessible, and useful outside the normal HTML/JavaScript path.

The implementation is intentionally split into independent issues so that each issue can serve as its scope contract and implementation record.

Product decision and order

P0 — freeze the shared contract

P1 — ship the high-value zero-JavaScript primitives

P2 — build the shared media foundation, then Zoom

P3 — add Gallery after the media contract is proven

Consumer-site integration and regression record

Dependency graph

contract (#4)
├── Badge/Kbd (#5)
├── Fields (#6)
├── FileTree (#7)
└── image foundation (#8)
    └── Image Zoom (#9)
        └── Gallery (#10)

Each completed vertical slice feeds the site integration issue.

Key scope decisions

  • Badge, Kbd, reduced Fields, and core FileTree are the first implementation wave.
  • Image behavior starts with a shared resolver and imgproc compatibility work; Zoom does not own a second resolution path.
  • Image Zoom is opt-in and page-scoped, uses one native <dialog>, and has no non-HTML runtime.
  • Gallery is later work and must reuse Zoom instead of creating another lightbox.
  • A standalone public icon shortcode is deferred. Components may use a small private, allowlisted icon registry where it materially improves their own UI.
  • Kbd uses a positional-only public API.
  • Fields advanced metadata (kind, location, since, deprecated, link) is deferred until the reduced MVP is proven.
  • FileTree does not read the filesystem, claim role="tree", or require JavaScript.
  • No TypeScript compiler, API playground, arbitrary color/class API, remote build-time image fetch, pan/drag/editor behavior, or second lightbox enters this roadmap.

Shared definition of done

Every public primitive must have:

  • strict required-parameter and enum validation with source position;
  • safe escaping and centralized URL handling;
  • stable HTML, print, Markdown, and RSS behavior;
  • readable output when JavaScript is unavailable;
  • responsive and dark-mode-safe styling;
  • English documentation and matching Simplified Chinese .zh.md documentation;
  • focused template/build tests plus the appropriate browser and accessibility coverage;
  • examples for long content and relevant mobile/dark states;
  • conditional runtime loading only when interaction is present and enabled.

Delivery gates

Do not collapse these into one “done” state:

  1. theme source and focused tests;
  2. local consumer-site rendering against an exact sibling checkout revision;
  3. theme release;
  4. consumer-site Hugo module pin and regression suite;
  5. hosted deployment verification.

Implementation-record convention

  • Keep each child issue's body aligned with the agreed scope and acceptance criteria.
  • Record design deviations, compatibility findings, test commands/results, and release evidence as issue comments.
  • Link implementation PRs and follow-up issues from the relevant child issue.
  • Close a child only when its own acceptance criteria are satisfied; later release/deployment gates stay open in the site issue when applicable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions