Foundation Interchange vs Native HTML: Choosing the Right Responsive Strategy

The responsive markup dilemma

You need a pricing table on desktop and a compact card stack on mobile. Writing a custom resize handler feels heavy and fragile. Foundation for Sites offers Interchange, a plugin that swaps HTML partials based on media queries. But is it the right tool? For images, native responsive HTML usually wins. For larger DOM subtrees, Interchange can simplify your code—if you accept its costs.

How Interchange swaps content

Interchange is declarative. You add a data-interchange attribute to an element and map named media queries to URLs or selectors. When the page loads, Foundation checks the current breakpoint and fetches only the matching partial via AJAX. The plugin then replaces the element's innerHTML.

Named media queries are aliases defined in your Foundation settings, such as small, medium, and large. Because the mapping lives in HTML, you avoid custom resize listeners. However, the swap happens after initial page load, which means the browser has already rendered the fallback content. That timing is the source of most trade-offs.

A worked example

Imagine a dashboard widget that shows a summary card on phones and a detailed data table on desktops. The base markup contains a simple fallback so users without JavaScript still see something useful:

<div class="widget" data-interchange="small.html, medium:medium.html, large:large.html">
  <p>Loading dashboard widget…</p>
</div>

Here, small.html holds the compact card, while medium.html and large.html hold richer layouts. On load, Interchange fetches only the file matching the current viewport. The partials must be same-origin or served with proper CORS headers; cross-origin requests will fail.

Because Interchange replaces innerHTML, any JavaScript behavior inside the swapped nodes is destroyed. If your table rows have click handlers or a carousel plugin, you must re-initialize them after the swap. Foundation provides a callback for this, but you need to wire it up manually.

Why images are different

For images, native HTML gives you <picture> and srcset. The browser evaluates these before layout, downloads only the appropriate resource, and never requires JavaScript. That means no layout shift, no duplicate requests, and no SEO risk from unexecuted swaps.

<picture>
  <source media="(min-width: 64em)" srcset="chart-large.webp">
  <source media="(min-width: 40em)" srcset="chart-medium.webp">
  <img src="chart-small.webp" alt="Quarterly revenue chart">
</picture>

Search engines reliably parse srcset and <picture>. Interchange partials fetched via AJAX are less predictable for crawlers, so critical content should stay in the initial HTML.

The trade-offs

• JavaScript dependency: If JS fails or is disabled, users see only the fallback. A slow connection can also delay the partial, causing layout shift.
• Duplicate requests: The browser may download the fallback image or content before the swap completes.
• Lost event listeners: Replacing innerHTML destroys existing DOM nodes. Focus can jump, breaking keyboard navigation.
• SEO uncertainty: Crawlers may not execute the media-query swap, so content hidden inside partials may not be indexed.

How to verify your setup

Open your browser's responsive design mode and step through the breakpoints defined in your Foundation settings. Watch the Network tab: only the partial matching the active breakpoint should load. Disable JavaScript and reload—you should see the fallback markup, not a blank container. Re-enable JavaScript and confirm that no duplicate IDs or orphaned handlers remain after a swap. Run Lighthouse before and after to measure layout shift and total blocking time.

Foundation for Sites has changed across 6.x releases. Before publishing, check the current reference documentation for your version to confirm attribute names, named media query aliases, and any deprecation notices.

Recommendation

Use native <picture> and srcset for every image. Reserve Interchange for cases where you must swap non-media DOM subtrees—entire components whose markup genuinely differs between breakpoints. Keep the initial HTML lean, provide a no-JS fallback, and re-initialize JavaScript after each swap.