Possible Content Payload Design
This is a parking-lot note for design controls intentionally removed from slide content payloads while the v1 content model stabilizes.
Current principle: root slide payload fields and promoted region payloads should describe what the slide contains. Layout and rendering decide how it looks. If per-payload styling returns later, it should live in an explicit override surface rather than mixing presentation controls into the base content payload.
Possible Shape
{
"title": "Revenue",
"left": {
"text": "Revenue grew 28%",
"design": {
"text": {
"alignment": "center"
}
}
}
}Open question: whether overrides belong inline on each content payload, in slides[].design, or in a reusable style catalog keyed by region key or payload type.
Deferred Fields
These fields were deliberately kept out of ContentPayload for now:
| Area | Candidate fields |
|---|---|
| Placement | position, size, zIndex, rotation |
| Text | style, fontSize, fontFamily, color, alignment, lineHeight, textTransform, verticalAlignment |
| Image/media | fit, borderRadius, shadow, opacity, crop, focalPoint |
| Chart | chartPreset, options, legend, showValues, showGrid, stacked, xAxis, yAxis, palette overrides |
| Table | tableStyle, stripedRows, compact, border colors, header colors |
| Shape | fill, stroke, cornerRadius, path |
| Code | theme, showLineNumbers, syntax-highlighting theme |
Decision Criteria
Bring these back only when there is a concrete renderer or authoring workflow that needs them. Prefer small, typed override objects over a large flat bag of visual fields on every content payload.