Responsive Edits

Every edit you save in the Visual Editor can be scoped to a viewport range. The snippet runtime checks the current window.innerWidth on each page load and only applies edits that match.

Viewport presets

The editor ships with four presets plus a custom range. Pick from the Viewport dropdown when editing an element.

• MOBILE: Applies when window.innerWidth is ≤ 767px.
• TABLET: Applies when window.innerWidth is between 768px and 1023px inclusive.
• DESKTOP: Applies when window.innerWidth is ≥ 1024px.
• ALL: Applies on every viewport. This is the default for new edits.
• CUSTOM(min, max): A user-defined range. Set the minimum and maximum in pixels; either bound is optional.

How the runtime applies viewport-scoped edits

When the snippet runs, it evaluates each change against the current window width. Edits whose viewport scope matches are applied immediately. The runtime also listens for resize events and re-evaluates the change list, so rotating a phone or resizing a desktop window keeps the right edits active.

The conceptual runtime logic looks like this:

type ViewportTarget = 'ALL' | 'MOBILE' | 'TABLET' | 'DESKTOP' | 'CUSTOM'interface ViewportScopedChange {  viewport: ViewportTarget  customMinWidth: number | null  customMaxWidth: number | null}function shouldApply(change: ViewportScopedChange, width: number): boolean {  switch (change.viewport) {    case 'MOBILE':      return width <= 767    case 'TABLET':      return width >= 768 && width <= 1023    case 'DESKTOP':      return width >= 1024    case 'ALL':      return true    case 'CUSTOM': {      const { customMinWidth: min, customMaxWidth: max } = change      return (min === null || width >= min) && (max === null || width <= max)    }  }}

Layering edits across viewports

You can save multiple edits to the same element with different viewport scopes. For example, you might want a short headline on mobile and a long one on desktop. The editor will create two separate changes (one scoped to MOBILE, one scoped to DESKTOP) and the runtime applies whichever matches the current width.

Previewing viewports

The editor's top bar exposes four canvas sizes through a labeled device switcher: a segmented control in the centre of the top bar with Desktop, Tablet, Mobile, and Custom segments. These aren't separate modes: your page always renders inside the same workbench canvas, and picking a size just changes the canvas's dimensions. Desktop fills the available area; Tablet, Mobile, and Custom size the canvas to the device viewport, so media queries fire as they would on the actual device, touch detection behaves like the device, and window.innerWidth reports the canvas dimensions rather than the host window's.

A label at the end of the switcher spells out the active size so you never have to guess from an icon: Tablet 820, Mobile 390. Desktop has no fixed width (it fills whatever space the workbench has), so it reads just Desktop. The segments themselves are compact icons that never change size or move, so you can click from one size straight to the next without the buttons shifting under your pointer. The rotate button sits in the same place for every size and only works for Tablet, Mobile, and Custom.

• Tablet renders an 820 × 1180 pixel canvas.
• Mobile renders a 390 × 844 pixel canvas.
• Custom exposes a width × height input pair: type any width between 320 and 4096 and the canvas resizes after a short debounce.
• The rotate button next to the segmented control swaps width and height, simulating landscape orientation. It appears whenever a non-desktop size is active.

Because there's only one canvas, switching sizes never reloads the page or resets the editor: your selection and unsaved edits carry across every size. Edits are persisted to the same change set no matter which size you captured them at, and there's no "snap back to Desktop" to catch you out.

The "Editing … only" badge

Picking a device size does one more thing beyond resizing the canvas: new edits are scoped to that viewport. So the top bar tells you, right next to the switcher, whenever that's about to happen:

• Editing Tablet only: while the Tablet size is active.
• Editing Mobile only: while the Mobile size is active.
• Editing custom width: while a Custom size is active (custom is a width range, not a single pixel value).

Only new edits pick up the active viewport: existing changes keep whatever scope they were saved with. Switch back to Desktop and the badge disappears: edits made at Desktop apply to all devices. The badge uses the same vocabulary as the viewport chips on the change cards, so a change made under "Editing Mobile only" shows a matching Mobile chip in the changes list.

When the editor launches from the snippet already on your page, the device canvas is a same-origin iframe (your page framing itself), so it loads without any extension or header rewriting. Because the frame and the host share an origin, media queries, touch detection, and window.innerWidth all report the device dimensions correctly. The retained browser extension path additionally strips frame-busting response headers (X-Frame-Options and the frame-ancestors directive of Content-Security-Policy) for un-snippeted or cross-origin pages; that rewrite is scoped to the active tab and removed automatically when you flip back to Desktop or close the editor.

Related

• Selectors: pair viewport scoping with a stable selector for the most reliable test.
• Execution order: see where viewport evaluation sits in the snippet lifecycle.