/Docs

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 ≤ 767px.
  • TABLET — Applies when window.innerWidth is between 768px and 1023px inclusive.
  • DESKTOP — Applies when window.innerWidth ≥ 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.
What you'll see
In the edit form, the Viewport dropdown lists the four presets and a Custom range... option. Picking custom opens two numeric inputs labelled Min width (px) and Max width (px). A live indicator at the bottom of the panel shows the current browser width so you can verify your edit will apply.

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.

Conceptual runtime logic
javascript
1function shouldApply(change, width) {
2  switch (change.viewport) {
3    case 'MOBILE':
4      return width <= 767
5    case 'TABLET':
6      return width >= 768 && width <= 1023
7    case 'DESKTOP':
8      return width >= 1024
9    case 'ALL':
10      return true
11    case 'CUSTOM':
12      const { min, max } = change.viewportRange
13      return (min == null || width >= min) && (max == null || width <= max)
14  }
15}

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.

Use CUSTOM for non-standard breakpoints
If your site uses bespoke breakpoints (e.g. a redesign at 1280px), switch to CUSTOM(min, max)and match your site's existing breakpoint exactly. Mixing the editor's presets with your CSS breakpoints can leave gaps where no edit applies.

Previewing viewports

The editor's toolbar exposes four device modes: Desktop, Tablet, Mobile, and Custom. Desktop mode edits the live page directly. Tablet, Mobile, and Custom mount the customer URL inside a real iframe sized to the device viewport — media queries fire as they would on the actual device, touch detection behaves like the device, and window.innerWidth reports the iframe's dimensions rather than the host page's.

  • Tablet renders an 820 × 1180 pixel canvas.
  • Mobile renders a 390 × 844 pixel canvas.
  • Custom exposes a width input — type any number 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.

Selection, edits, and saving all work the same way in iframe mode as in desktop mode. Edits captured against an element inside the iframe are persisted to the same change set; flipping back to Desktop replays them onto the live page.

While iframe mode is active, the AvsB extension strips frame-busting response headers (X-Frame-Options and the frame-ancestors directive of Content-Security-Policy) so even pages that normally refuse to be embedded will load. The header rewrite is scoped to the active tab and removed automatically when you flip back to Desktop or close the editor — every other tab in your browser is unaffected. You can audit what the extension is doing in real time at chrome://extensions → AvsB Dev Tools → details → View site permissions.

Pages that resist being embedded
A small number of pages run JavaScript that detects being framed and forces a top-level navigation. The editor watches for these patterns and shows a banner if a page resists embedding — the device toggle automatically reverts to Desktop so your work isn't lost. The fix on the customer side is to remove the legacy frame-bust script; in the meantime, edit those pages in Desktop mode.
Resize behaviour and layout shift
Changing the viewport scope of an existing edit will not retroactively update sessions that already loaded the page. Visitors who were bucketed under the previous scope will continue to see the variation until they reload. This is rarely a problem for marketing tests, but worth knowing during QA.
  • Selectors — pair viewport scoping with a stable selector for the most reliable test.
  • Execution order — see where viewport evaluation sits in the snippet lifecycle.