Jewellery Template

Quick Start

1. Upload the folder. It is static: index.html, collection.html, assets/style.css, assets/script.js, assets/img/. No build step, no dependencies to install. Both pages share one stylesheet and one script, and every section initialiser returns early when its markup is absent, so each page silently skips what it does not have.

2. The three script tags at the bottom of index.html load GSAP, ScrollTrigger and Lenis from a CDN. Leave them as they are, or self-host the files and change the paths.

Code snippet omitted: it ships with the download.

3. Keep this line in <head>, above the stylesheet:

Code snippet omitted: it ships with the download.

It runs before the first paint so that reveal start states apply without a flash. assets/script.js removes the class again if GSAP fails to load, which is what makes a blocked CDN degrade to a plain readable document instead of a page of hidden content. Moving this into the body reintroduces the flash.

4. Replace the copy and the photographs. Every section is independent: the script skips any section whose markup is not there, so you can delete whole sections without touching the JavaScript.

Sections and their options

Nav

Four links, a wordmark and the selection control on one 68px row. --nav-h in the token block sets the height and the scroll offset for the anchor links together; change it in one place. There is deliberately no call to action in the nav beyond the selection count, because a house that takes commissions does not need one above its own name. The row stays on one line down to 320px, which is what the tracking steps at the 560, 400 and 345px breakpoints are for: lengthen a label and check those.

1. The hero, "the vitrine"

The photograph is 56% of the frame, pushed off the right edge and up through the top edge so the frame crops it on two sides, and the indented headline line runs underneath it.

To change	Where
How far the piece bleeds off the top	--piece-top on .hero-frame
How wide the piece is	width on .hero-piece, and the 56vw inside --piece-h to match
How far the second headline line runs under it	margin-left on .hero-line--indent
The cast shadow's angle and softness	transform and filter on .hero-cast

The piece is square, and top cannot take a percentage of width, so its height is restated once as --piece-h and both the image and the shadow read it. If you change the image's width you must change that value too.

The headline lines are white-space: nowrap, so they stay lines. That is what --step-display is clamped for at each breakpoint; if you write a longer headline, bring the clamp down with it or the line will be clipped by its mask.

2. The rake light

Two copies of one photograph, stacked. The lower copy is graded down to near darkness, the upper copy is graded up and revealed through a soft band that follows the light. Every number the interaction is tuned by is in one RAKE block at the top of assets/script.js:

Key	Default	What it does
follow	0.42	Seconds the light takes to reach the pointer
shadowLag	0.085	How far the shadow trails the light. Lower is more lag
swing	54	Degrees the shadow swings, counter to the light
stretch	0.9	Extra shadow length once the light is off centre
overshoot	16	Degrees per unit of speed, thrown past the resting angle
speedCap	6	Speed is clamped here, so a flick cannot spin the shadow
smearGain / smearMax	0.55 / 3.2	How far a fast sweep elongates the streak, and the cap
lead / leadMax	26 / 130	How far ahead of the light the streak rides, in px
idleAmp / idleSpeed	0.17 / 0.42	How far and how fast the light drifts at rest
settle	1.6	Seconds to blend from the last pointer position into that drift
scrollFrom / scrollTo	0.08 / 0.92	Where the scroll-driven version starts and ends

Two things live in CSS rather than in the script:

• The exposure grade. .rake-img--base and .rake-img--lit are the same file with different filter values. Raise brightness on the lit copy for a harder light, lower brightness on the base copy for a darker room.
• The softness of the band. --band-core, --band-mid and --band-edge on .rake-img--lit set how wide the lit region is and how far it feathers. Keep a solid core: a band that is feather all the way through loses the edge that makes it read as light rather than as a blur.

The warmth of the lit region comes from sepia() on the lit copy, scaled by --warmth, which the script raises as the light crosses the middle of the piece. That is the only warm value the CSS produces anywhere, and it is deliberately tied to the light rather than painted in.

3. The collection

An asymmetric twelve-column grid at four scales. Piece positions are five explicit grid-column / grid-row rules on .piece--lead through .piece--wide, with the wide piece running past the right edge of the frame. Add or remove a piece by editing those five rules; the grid does not derive itself from the content.

Each plate is a fixed-ratio window with the photograph 12% taller than the window, centred. That overscan is what the drift moves within. data-drift on a plate is the travel in percent of the image height, applied as a scrubbed yPercent. Keep it under about 5 or the photograph will show a gap at one edge as it travels. Remove the attribute to stop a tile drifting.

4. The atelier

An asymmetric split: the photograph runs to the left edge of the window and lifts above the seam with the section before it, set by margin-top on .atelier-media. The oversized numeral is .atelier-numeral, and it is the one place malachite is used as display type on a light surface.

5. Commission

The form validates inline while assets/script.js is running and never submits. To make it real:

1. Set action on the <form> to your handler, and method to what it expects.
2. In initForm in assets/script.js, remove the e.preventDefault() in the submit handler, or replace the success block with a fetch to your endpoint.

Without JavaScript the form falls back to the browser's own validation, since novalidate is only added by the script.

6. Footer

Four columns above a hairline. Nothing in it is wired to anything.

The collection page

collection.html is the second page: a shop index of twelve pieces in a regular four column grid, a filter, and a closing band back to the commission form. The nav on both pages links to both and marks the current one with aria-current="page".

To add a product, copy one <article class="card"> block and change the image, name, spec and price. Set data-category to one of rings, earrings, bands or chains, and add a matching chip to .filter-chips if you introduce a new category. Give it a unique data-piece id as well, which is what the cart stores it under (see Cart below). The count in the bar is derived, not written, so it stays correct.

The filter hides and shows cards, updates each chip's aria-pressed, and reflows the grid with GSAP Flip. Two things about it are deliberate:

• Without JavaScript every piece is visible. The cards are all in the markup with nothing hidden, so the page is a complete product index before any script runs. The chips are real buttons that simply do nothing until the script wires them up. Nothing is ever unreachable.
• The grid's height is held during the reflow. Flip lifts the surviving cards out of normal flow, which would otherwise collapse the grid to nothing and make the footer lurch up and snap back on every filter press. The script pins the height and eases it to its new value instead.

Under prefers-reduced-motion the filter still filters; it just swaps instantly with no reflow animation.

collection.html also loads GSAP's Flip plugin, which index.html does not need. Drop that one script tag if you remove the filter.

Cart

Read this before you sell anything with it. The cart is front end only. It keeps the selection in the visitor's own browser, in localStorage, and it talks to nothing: no server, no payment provider, no order. The checkout button is a stub. It says so on the panel, and pressing it says so again. It cannot take money, and it must not be left as it is on a site that is trying to. Wiring it to a real provider is the job below, and it is the only thing between this template and an actual shop.

Nothing in it invents a trust signal either: there is no padlock, no provider logo and no claim about anyone else's basket. If you add those, add them because they became true.

What it is

• A selection control in the nav on both pages, with a live count. Below 560px the word gives way to the count plate, because the nav is one line at every width and there is no room for both.
• An add line under every piece, on the five in the home page teaser and on all twelve on the collection page.
• A slide-out drawer listing each line as a docket: name, spec, unit price, quantity, line total, then a subtotal and the checkout button.
• One selection across both pages. The same data-piece id on the home page teaser and the collection page is one line item, not two.

The control, the add lines and the drawer are built by the script, not written into the two pages. That is deliberate: with JavaScript off the pages are a complete, readable catalogue with no buying chrome at all, rather than buttons that cannot work. A dead Add button is worse than no Add button.

To add a product

Copy a <article class="card"> on collection.html (or a <figure class="piece"> in the home page teaser) and give it a unique data-piece id:

Code snippet omitted: it ships with the download.

That is all the cart needs. The name, spec and price come out of the card's own caption (.card-name / .card-spec / .card-price, or .piece-name / .piece-spec / .piece-price in the teaser), so the price in the drawer cannot disagree with the price on the card. Prices are parsed by stripping everything that is not a digit or a decimal point, so £6,400 and £1,950.50 both read correctly. Change a price in the markup and any selection already sitting in a visitor's browser is restated the next time they load the page.

Use the same id in both places when a piece appears on both pages.

To wire a real checkout

Everything is in initCart in assets/script.js, under the comment marked CHECKOUT GOES HERE:

Code snippet omitted: it ships with the download.

items at that point is the whole selection, and its shape is the shape held in localStorage under the key halvard-selection:

Code snippet omitted: it ships with the download.

price is in pence, as a whole number, so a subtotal is integer addition and never picks up a rounding error. Multiply by qty for the line, divide by 100 only to display.

Three ways people usually take it from here:

1. Stripe Checkout. POST items to your own endpoint, create a Checkout Session server side (never with a secret key in this file), then window.location = session.url.
2. Shopify, or any headless store. Map each id to a variant id and redirect to /cart/{variant}:{qty},{variant}:{qty}, or use the Storefront API to create a cart and redirect to its checkout URL.
3. Snipcart or a similar drop-in. Let it own the cart entirely: add its script, put its data attributes on the add buttons, and delete this section from script.js and its styles from style.css.

Whichever you choose, delete the two stub lines above and the honesty note under the button (CART.copy.stub) at the same time, and only then. That note is what stops the page claiming something it cannot do.

Copy and tuning

Everything the cart says, and every number it is tuned by, is in one CART block at the top of the section in assets/script.js:

Key	Default	What it does
key	halvard-selection	The localStorage key
version	1	Bump it if you change the stored shape
currency	£	The symbol prefixed to every price
maxQty	99	The ceiling on one line's quantity
openTime / closeTime	0.45 / 0.3	Seconds the panel takes to slide
addedFor	1.6	Seconds the add line reads "Added"
copy		Every visible string, including the two honest ones

How it behaves

• Adding does not open the drawer. The count changes, the line says "Added" for a moment and the count plate steps up. A panel that throws itself over the page on every add makes buying three things a fight.
• Quantity changes patch their own row rather than rebuilding the list, so the button you just pressed stays under the pointer and keeps focus. Removing a line moves focus to the same control on the next line, or to Close when the list has emptied.
• The empty state is designed, because it is the first state most visitors see: a line of copy and a link back into the collection, with the subtotal and the checkout button removed rather than shown with nothing in them.
• Two tabs stay in step. A change in one is picked up by the other.
• A hostile or damaged store is discarded, not trusted. localStorage is a text file the visitor can edit, so every row is re-validated on read and anything that is not a real line is dropped. If storage is unavailable (private browsing, a full quota) the cart still works for that page view; it just will not survive the next navigation.

Accessibility and fallbacks

• Without JavaScript: no cart control, no add lines, no drawer, and both pages are complete catalogues with every piece, price and link reachable.
• Reduced motion: the drawer opens and closes and is fully usable, it just does not slide or fade. Handled in both the CSS and the gsap.matchMedia branch.
• Keyboard: the drawer is a real role="dialog" with aria-modal, labelled by its heading. Focus moves into the panel on open and is trapped while it is open, Escape closes it, and focus returns to the control that opened it. Everything behind the drawer is inert while it is open, and reachable again the moment it closes.
• Screen readers: one polite live region, outside the drawer so it is never made inert, announces every count change whether the panel is open or shut. Quantity and remove buttons name their piece ("One more Selv drops"), never just "plus" and "minus".
• Touch: the panel leaves a strip of the page uncovered at every width, so it can always be dismissed by tapping outside it as well as by the Close button. Quantity buttons grow to 44px on a coarse pointer.
• Smooth scroll: the list carries data-lenis-prevent, without which Lenis swallows the wheel and the drawer will not scroll with a mouse. Keep it if you restyle the panel.

Palette

Four values, and every other colour on the page is one of those four at another opacity. A reskin is an edit to this block at the top of assets/style.css and nothing else:

Code snippet omitted: it ships with the download.

Change each hex and its RGB triple together. Every translucent value in the stylesheet, including the mask stops in the rake light, resolves from one of those triples; a hex changed without its triple leaves rules, dimmed type and shadows mixed from the old colour.

The header comment above the block records the contrast ratio of every pair as it is actually used, including the dimmed variants composited over each surface they land on and the form colours on the malachite field. If you repaint, re-measure those: the two faint variants are what carry most of the reading copy, and they are the pairs that fail first.

There is no palette switcher, by design. The palette is what this template is.

Images

Photographs ship as bundled, optimised WebP derivatives in assets/img/ with the art direction baked into the pixels. Nothing is hotlinked and nothing is fetched at runtime.

File	Size	Where
hero-ring.webp	1600 x 1600	The hero piece
rake-piece.webp	1400 x 1400	The rake light, used twice
piece-01.webp	900 x 1200	Collection, the large one
piece-02.webp to piece-04.webp	600 x 600	Collection
piece-05.webp	1400 x 700	Collection, the wide one
piece-06.webp to piece-12.webp	600 x 800	The collection page
atelier-bench.webp	1400 x 1750	The atelier

To swap a photograph, drop a replacement into assets/img/ under the same name. Match the listed dimensions and nothing moves. Every photograph has a solid colour behind it from the token block, so the layout holds while images load and does not collapse if one is missing.

To regenerate the whole set from new sources, edit the src paths in assets/img-manifest.json and re-run the asset build:

Code snippet omitted: it ships with the download.

The manifest also carries the grade that makes eight separate photographs read as one campaign: a light desaturation, a small cool hue shift, and a per-image brightness. Set brightness per image, not globally. Sources differ in exposure, and matching perceived brightness rather than nominal brightness is the whole reason a mixed set coheres; expect one photograph to need a very different number from its neighbours.

Note that rake-piece.webp is graded slightly down in the manifest. The section brightens a copy of it in CSS, and a source that is already bright clips to white the moment the light passes over it.

Why the photographs have no edges

Every product shot on a chrome ground is blended into it rather than placed on it. Each image carries mix-blend-mode: multiply and a --lift value: brightness() raises the photograph's seamless studio backdrop to white, and multiplying white by the ground gives the ground exactly, so the rectangle disappears and only the metal, the stone and the piece's own shadow survive as darker values sitting on the field.

--lift is per image and it is 255 divided by that photograph's backdrop brightness. Set too low it leaves a visible dark rectangle; set too high it eats the metal. The values live next to the pieces in assets/style.css for the home page and inline on each <img> on the collection page. Retune them whenever you swap a photograph, and check against a plain screenshot: if you can see the plate's edge, the lift is too low.

This is also why mixed source shapes do not matter on the collection page. The cards hold one 3:4 ratio and the images sit inside them with object-fit: contain; because the letterboxing has the same value as the ground, a landscape piece and a portrait piece look identical in treatment.

Accessibility

• Contrast. Every pair on the page was measured as used, composited, at the size it is used, and the results are in the :root header comment in assets/style.css. Nothing relies on the 3:1 large-text allowance.
• Reduced motion. Under prefers-reduced-motion the page is a designed static document, not the animated one with the motion switched off. The rake light freezes at a flattering angle with the piece lit and the shadow at rest, and every reveal target is restored by CSS independently of the script.
• Keyboard. The rake light takes Arrow Left and Arrow Right. Its focus stop is added by the script and removed on teardown, so it never appears on a page whose JavaScript did not load. Focus outlines are visible on every ground and switch colour on the two dark sections.
• Touch. A coarse pointer gets the rake light driven by scroll progress through the section rather than nothing, with the smear channel dropped because there is no whip gesture to smear.
• No JavaScript. Every piece of content is readable with scripting off. The light position and the warmth are ordinary CSS custom properties with sensible initial values, so the piece in the rake section is already lit.
• Forms. Labels sit above inputs, errors sit below them and are wired with aria-describedby, and no placeholder is used as a label.
• The cart. A real dialog: focus moves in, is trapped, and returns to the control that opened it; Escape closes it; the rest of the page is inert while it is open. One live region announces every count change. The whole of it is built by the script, so with scripting off there is no cart control anywhere and nothing on either page is unreachable. Full detail in the Cart section above.

Dependencies

Library	Version	Required
GSAP	3.15.0	Yes
ScrollTrigger	3.15.0	Yes
Lenis	1.3.17	Optional

Smooth scroll is opt-out. Add data-smooth="off" to the <html> tag to ship without it, or append ?smooth=off to the URL to compare a page both ways without editing anything. It is also off automatically under prefers-reduced-motion, which Lenis does not honour by itself.

If you remove Lenis, delete the whole initLenis block at the bottom of assets/script.js rather than part of it. The shared-clock wiring, the opt-out check, the refresh listener and the teardown each fix a different bug, and half of that block reads as correct while still being broken.