Click-to-edit

Click-to-edit lets content authors click any element in the Studio live preview to jump straight to the field that produced it. It works through a combination of template annotations you add to your Astro components and a runtime fallback that auto-matches rendered elements to frontmatter values — so click-to-edit is available out of the box, and becomes progressively more reliable as you annotate more of your templates.

Two ways click-to-edit works

Studio uses two complementary mechanisms to wire up click targets in the preview:

Mechanism	How it works	When it applies
Explicit annotations	You add data-quant-field attributes to elements in your Astro templates	The most reliable path — works for every field type, including enums, dates, images, and nested objects
Auto-annotation fallback	At preview time, Studio walks the rendered DOM and matches element text (or img src/alt) against frontmatter values	A best-effort fallback for unannotated templates — catches simple string fields but can miss transformed or computed values

Explicit annotations always take priority. The auto-annotation pass only runs on elements that aren’t already annotated, so adding data-quant-field to a template never breaks the fallback for fields you haven’t annotated yet.

Explicit annotations

Add a data-quant-field attribute to any element whose text content comes from a frontmatter field:

---
const entry = Astro.props.entry;
---
<article data-quant-collection={entry.collection} data-quant-slug={entry.slug}>
  <h1 data-quant-field="title">{entry.data.title}</h1>
  <p data-quant-field="description">{entry.data.description}</p>
  <img data-quant-field="image" src={entry.data.image} alt={entry.data.title} />
  <div data-quant-field="body">
    <slot />
  </div>
</article>

Two context attributes make click-to-edit unambiguous when a page renders entries from multiple collections:

• data-quant-collection — the collection name for the surrounding context
• data-quant-slug — the slug of the entry being rendered

Studio’s preview looks for the nearest ancestor carrying these attributes to decide which entry a clicked field belongs to. If your layout only ever renders one entry per page, you can set them once on the outermost wrapper and let every field inherit.

The body field

Wrap your <slot /> (or rendered markdown content) in an element annotated as data-quant-field="body" to enable inline editing of the Markdown body:

<div data-quant-field="body">
  <slot />
</div>

Inside a body region, Studio routes clicks on individual text elements (p, h1–h6, li, td, th, figcaption, blockquote > p) into an inline editor — you can type directly into the preview. While an element is in inline edit, Cmd/Ctrl+B and Cmd/Ctrl+I wrap the current selection in Markdown bold/italic markers. Clicks on non-text elements (images, custom components, embeds) open the side-panel field editor instead.

Code blocks inside the body (<pre> / <code>) are deliberately excluded from inline editing so syntax stays intact — they fall through to the side panel.

Field types and routing

Not every field is edited the same way:

Field category	Click behaviour
String / number / date / enum	Inline edit in place (for simple field type), or side-panel editor for complex controls
Image / file	Opens the media browser in the side panel
Array / object	Opens the structured editor in the side panel
Body (markdown)	Inline edit for text elements, side panel for non-text elements

Studio decides which control to use based on the field’s Zod type in src/content/config.ts. You do not need to configure anything beyond the data-quant-field attribute — the runtime resolves the appropriate editor from the schema.

Auto-annotation fallback

When Studio loads a preview, it runs an auto-annotation pass on any elements that don’t already carry data-quant-field. The fallback:

• Walks candidate elements inside <main>, <article>, or the document body (headings, paragraphs, spans, links, images, short-text divs)
• Matches each element’s rendered text against your entry’s frontmatter values — exact match, or the element text starts with the field value
• For <img> elements, matches against src (substring) or alt (exact)
• Picks the first unmatched field for each element and tags it with data-quant-field + data-quant-editable
• Annotates the most likely body wrapper (main article, main .prose, article, or main) as data-quant-field="body" if it contains block-level content

This means click-to-edit works immediately on most Astro projects imported into Studio — you do not need to annotate anything before the first preview. The trade-offs:

• Transformed values miss. If your template renders {formatDate(entry.data.publishedAt)} as 19 April 2026, the raw value in the frontmatter is a Date object, so the text won’t match.
• Enums miss when labels differ from values. type: 'news' rendered as News won’t be auto-annotated.
• Duplicate text matches the first field only. If two fields share the same value, only one element gets annotated.
• Derived text is not editable. Computed slugs, joined tag strings, and other transformations can’t be linked back to an editable field.

Adding data-quant-field attributes to templates you care about avoids all of these cases.

The annotation readiness check

When you import a Studio project from GitHub, the import wizard shows a Click-to-edit Readiness panel listing every content collection with a page template. For each field in the collection’s schema, it reports one of three states:

State	Meaning
Annotated	A data-quant-field="{field}" attribute was found in the template — click-to-edit is explicit and reliable
Rendered but not annotated	The field value is used in the template, but no matching data-quant-field attribute was found — auto-annotation will attempt to cover it at preview time
Not rendered	The field is defined in the schema but does not appear in the template — nothing to click on

The check is informational only — import always proceeds regardless of coverage. Its purpose is to show you where explicit annotation will improve click-to-edit reliability. A template with 100% annotated fields has the most predictable editing experience; a template with zero annotations still works via the auto-annotation fallback, but with the limitations above.

Studio auto-adds data-quant-field attributes to templates it scaffolds for new collections, so generated templates start at full coverage.

Debugging click-to-edit

If a click in the preview does nothing, check the following in order:

1. Is the element inside a context? The nearest ancestor needs data-quant-collection and data-quant-slug — without them, Studio can’t tell which entry a field belongs to.
2. Is the element annotated, or does auto-annotation cover it? Open DevTools on the preview iframe and look for data-quant-field on the element you clicked. If it’s missing, the auto-match heuristic couldn’t find a frontmatter value for the text — add an explicit annotation.
3. Is the field name correct? The value of data-quant-field must match a field name in the collection’s Zod schema exactly. Typos silently fall through.
4. Is the element a code block inside the body? Clicks inside <pre> / <code> intentionally fall through to the side-panel editor rather than inline edit, to protect code formatting.

Next steps

• Visual editor — See how click-to-edit integrates with the live preview and side-panel field editors
• Content schemas — Understand how Zod field types drive the editing controls that click-to-edit routes to
• Creating a project — Review the import wizard and its readiness checks