PDP Content Accordion That Borrows the Premium Theme's Collapsible Contract

A product-page accordion block that reuses Palo Alto's own data-collapsible-* behavior wiring while supplying its own heading semantics, CSS-variable theming and a responsive table layout for the long-form panels merchandisers author per product.

A premium Shopify theme ships one accordion behavior, bound to its own data attributes, and a second open-close system on the same product page fights it. This snippet keeps Palo Alto's collapsible contract and supplies its own markup, brand-token colors and a two-column table layout, so merchandisers author long-form panels per product inside a component that looks nothing like the vendor's default.

The Problem

A premium theme's accordion is a package deal. The vendor ships the markup, the styling and the JavaScript together, and the JavaScript only recognizes the markup it was written for. If you want a panel that behaves like the theme's accordion but looks like something else, the platform gives you two bad options: restyle the vendor's markup and lose the fight with its stylesheet's specificity on every theme update, or write a second accordion and put two open-close systems on one page.

Three Ships needed the second look. The product pages carry long-form educational panels — clinical results tables, ingredient breakdowns, embedded video — that content marketers author per product, and the brand wanted those panels to match its earlier accordion design rather than Palo Alto's default. The content varies wildly from product to product, so a fixed field set would not have held it.

The Constraint

Palo Alto 5.8.0 already runs a collapsible behavior bound to three attributes: data-collapsible-trigger, data-collapsible-container and data-collapsible-content. Its compiled runtime finds those attributes and animates open and close. Re-implementing that meant two competing systems reacting to the same clicks, two sets of ARIA state, and two animations to keep in step. Removing the vendor's was not an option either — the rest of the product page depends on it.

The panel content was the other fixed point. A results table for one product, an ingredient story for another, a video for a third: the schema could not enumerate that in advance, so the body had to be authored per product in the block rather than composed from named fields. And because the accordion had to be available to every product layout, it had to render from the shared product snippet, not from a single template.

What We Built

pdp-accordion.liquid is a block-level snippet rendered from product.liquid, the shared product snippet, so every PDP layout that uses it gets the accordion as an available block.

The borrowed contract. The snippet emits Palo Alto's data-collapsible-trigger, data-collapsible-container and data-collapsible-content attributes exactly as the theme's own accordion does, and nothing else from the vendor's accordion. The theme's compiled runtime sees attributes it already understands and drives the open-close behavior; it never knows the markup around them is not its own. One accordion system on the page, as the theme intended, wrapped in markup the theme did not write.

The markup. Each accordion is an <h2> wrapping a .pdp-accordion__title button, with aria-controls pointing at a panel whose id is PdpAccordionPanel--<block_id>. The toggle icon reuses the theme's own icon-toggle-plus and icon-toggle-minus snippets, so the visual language of "open" and "closed" is consistent with every other disclosure on the storefront even though the panel around it is not.

The theming. Color is carried by three CSS custom properties — --pdp-accordion-bg, --pdp-accordion-border and --pdp-accordion-text — set inline from block settings, with the brand's own palette as the defaults. Vertical rhythm comes from margin_top and margin_bottom settings. A merchandiser who never opens the color pickers gets a panel that already looks intentional.

The content conventions. The accordion's stylesheet ships a .kb-table / .kb-row layout: a two-column grid for results and ingredient tables that collapses to one column under the mobile breakpoint. It also carries an aspect-ratio rule that flips an embedded iframe from landscape to portrait on mobile, because a horizontal clinical-results video that is legible on desktop is a letterboxed sliver on a phone. Both conventions are documented by the stylesheet rather than by a schema field: the merchandiser writes the markup, the stylesheet lays it out.

Why This Way

The snippet's own comment states the intent: same behavior and wiring as the theme's default accordion, styled to match the legacy look. Borrowing the behavior contract instead of the markup is what keeps one accordion system on the page while allowing a completely different visual treatment. The vendor's runtime does the animating and the state; we do the semantics and the paint.

What that buys is a small file and no JavaScript of our own. What it costs is a dependency on attribute names we do not control. Palo Alto's collapsible contract is an implementation detail of a theme we license, not a documented API, and a future theme version could rename those attributes or change what its runtime expects to find inside them. If that happens, this accordion stops opening on the same day the vendor's does — and the fix is in one snippet, which is the reason we thought the dependency was worth taking. The alternative, our own disclosure runtime, would have been more code to own for a behavior the page already had.

Why Not an App

Product-tabs and accordion apps hold panel content in the app's own database and render it into the page with a script after load. On this storefront that would have meant a third open-close system — the theme's, the app's and whatever the app used for its own animations — and product content living in a vendor's admin, separate from the product it describes.

Keeping the body in a theme-editor block keeps the content in Shopify. A merchandiser edits the panel in the same place they arrange the rest of the product page, and the accordion is in the server-rendered HTML rather than injected after the theme's runtime has already initialized.

Implementation Notes

• Rendered from product.liquid, the shared product snippet, so the block is available to every PDP layout that uses it rather than to one template.
• The panel id is derived from block_id, so several accordions on one product page stay independent — each button's aria-controls targets its own panel.
• The three color properties default to the brand's own palette when a setting is blank, so an unconfigured block still renders on-brand rather than transparent.
• The optional .kb-table / .kb-row convention is documented by the stylesheet, not by a schema field. The block's schema stays small; the layout vocabulary lives in CSS.
• The toggle icons are the theme's own icon-toggle-plus and icon-toggle-minus snippets, so the plus-to-minus transition matches every other collapsible on the storefront.
• Margins are block settings (margin_top, margin_bottom) rather than fixed values, because the accordion sits at different depths on different product layouts.

Edge Cases

• A blank heading suppresses the entire accordion. There is no empty toggle: an unconfigured block renders nothing rather than a button with no label.
• Color settings left unset fall back to the brand defaults, so a partially configured block cannot produce white text on a white panel.
• Several accordions on one product page each get their own PdpAccordionPanel--<block_id> target, so opening one never toggles the state of another.
• The .kb-table grid collapses to a single column under the mobile breakpoint, so a two-column results table remains readable on a phone rather than compressing into unreadable cells.

Platform Primitives Used

• liquid-schema-settings — the heading, colors, margins and panel body are block settings; the schema is deliberately small.
• theme-blocks — the accordion is one block type in the shared product snippet's block loop, added and reordered by a merchandiser in the theme editor.
• css-custom-properties — three properties carry the block's colors from settings to stylesheet, with brand defaults when a setting is blank.

Where It Runs

The product detail page. Because the snippet renders from the shared product snippet, it is available as a block to every product layout that uses that snippet, and a merchandiser decides per product which panels exist and in what order.

What This Demonstrates

• Design system and reusable component library — the primary capability: a component that extends a premium theme's behavior contract instead of forking it, themed through custom properties with brand defaults.
• Metafield-driven PDP content blocks — long-form product education authored per product in the admin rather than hard-coded in Liquid.
• Accessibility remediation — a heading-wrapped button with aria-controls is the disclosure pattern the vendor's default did not give this brand's design.

How We Know

One Liquid snippet from the theme, roughly 140 lines, including its stylesheet and the comment that records the design intent. Documented from the code; no client-side record of the decision survives. The snippet's comment is unusually explicit about what was being attempted, which is why we are comfortable stating the intent — but the request that led to it, and who made it, are not in this corpus.

Related Builds

• Configurable PDP block system on the Palo Alto theme (Recharge widget placement, size charts, siblings, quick view) — the block loop this accordion is one entry in, and the same storefront's broader pattern of extending the vendor's product page.
• Metafield-driven product information tabs with mobile accordion and variant refresh — a different storefront on Dawn, where the disclosure runtime is ours because the theme's was not worth keeping.
• Metafield-driven PDP content system: auto-built accordions, need-to-know strip and campaign widgets — the third storefront, where accordions are generated from metafields rather than authored per block. Three clients, three answers to the same panel.

The Buy-vs-Build Question

A product-tabs app buys a panel system with its own runtime and its own content store. Building the block bought one accordion system on the page and content that lives with the product, and cost a dependency on the theme's undocumented attribute names. Whether to extend a premium theme or own a section library is the subject of the theme section library and design system decision page.

Provenance & Evidence

• Client: Three Ships — threeshipsbeauty.ca
• Surface: Product detail page
• Complexity: Medium
• Attribution: Deploi-authored. The snippet, its markup and its styling are ours. It runs inside Palo Alto 5.8.0 by Presidio Creative, a paid premium theme the client licenses, and it deliberately drives the theme's own collapsible runtime rather than shipping one of its own.
• Status: Live, verified 2026-09-06
• Evidence: One Liquid snippet from the theme
• Confidence: Moderate — documented from the code; no client-side record of the decision survives
• Primary capability: Design system and reusable component library

Want Product Pages That Teach Without Fighting Your Theme?

You dream it. We build it. If your premium theme's components are close but not right, Contact us today and we'll show you where extending beats forking — and where it doesn't.