Exporting

Saving and exporting are different acts, and the buttons are deliberately separate. Save keeps the working files this app reopens. Export produces something to hand over — and what “something” means depends entirely on who is receiving it.

Everything written is real CSS with real tokens, because there was never a build step to strip out. The three arrangements differ only in how the same output is laid on disk.

The project

Export, beside Save. Everything goes into export/ inside the project.

One page	a single .html with the whole stylesheet inside it
Three files	index.html, styles.css, globals.css, linked as they are now
Components	one folder per block — hero/hero.html and hero/hero.css — plus the whole sheet, globals.css, and site.css

And, under As a picture, the same page as something to look at:

PDF	vector, one page as tall as the design. Text stays selectable
PNG	the page at twice the size, with its background
JPG	the same picture, smaller file, no transparency

One page

Everything in one file, for a client or a link. The <style> block sits at the foot of the body, so the markup is the first thing anybody opening it reads.

A picture of the page

For a client, a deck, a message — the thing you send when the person receiving it is not going to open a folder.

It is rendered, not screenshotted. The canvas is a scaled, panned frame with selection chrome drawn over it, and a picture of that is a picture of the app. What gets rendered is the same markup the one-file export writes, loaded fresh and given time to settle, so what you get is the page rather than the tool.

The width is the one on the scrubber. There is no paper size and no margin, for the same reason the artboard has none: a design on A4 with a two-centimetre border is not the design. So a picture taken at 720 is the page at 720 — which is the honest way to show somebody that it holds up narrow.

Two things it does quietly. It waits for the fonts and the pictures and then measures until the height stops changing, because a webfont resolves on its own timetable and a page measured too early is the fallback’s metrics rather than yours. And it fills the hairline that some renderers draw between two touching full-bleed sections — a transparent border pulled back by an equal margin, so nothing moves. Both belong to the picture: neither reaches the HTML and CSS you hand over.

Components

A folder per block, which is the shape Boosh CMS and FEWD Studio both expect: a page is a flat stack of sections and each section is a component.

Which rules go where is BEM, read literally — .hero__title belongs to hero and nothing has to be guessed. The match is on the whole first class, never a prefix: .section-2 starts with the text .section and is a different block, and splitting on prefixes would put one section’s rules into another’s file and leave neither complete.

The harder case is a rule named after something else — a .stat-box sitting inside the hero. BEM says nothing about where it is used, so:

• used by one section → it goes in that section’s file
• used by more than one → genuinely shared, so site.css
• used by none — a reset, a utility, something written by hand → site.css

Because the folders have to add up to the page. A hero/hero.css that does not contain what hero needs is not a component.

Assets

The .svg in assets/graphics is the working file — the one the artboard reopens and edits. An export is a finished thing for somebody else to use.

They are kept apart on purpose. A folder holding both is a folder where nobody can tell which logo.svg is the one to edit, and the answer six months later is whichever has the later date, which is not an answer.

SVG	the drawing itself. The only export that keeps your tokens
PDF	vector, for print. Curves stay curves, text stays text
PNG	pixels, with transparency, at 1× to 4×
WebP	the same, and much smaller
JPG	pixels, no transparency — so it gets a white ground rather than a black one

The PDF is made by Chromium itself, printing the drawing offscreen — a real vector PDF rather than a picture of one.

A file you saved earlier

Every row in the library has its own Export, and there is an Export all for the folder you are looking at — which is the whole reason an icon set is a set.

Neither opens the drawing. Opening it would throw away whatever is on the artboard, and exporting twenty icons should not cost you the twenty-first you were in the middle of.

The library lists .svg only, because those are the ones you can open and edit. An exported PNG is a finished file, not a drawing, and it belongs in the folder rather than in the list.

A raster export paints the colours you can see. Tokens are resolved first, because a var() inside an image cannot reach the page’s custom properties: the SVG becomes its own document with its own root and every fill would fall back to its saved snapshot. Right for a file on disk, wrong for an export of what is on screen.

What an export is not, yet

The export sits inside the project and points at its assets — paths are rewritten to reach them, one level up from export/ or two from a component folder. It is not a self-contained bundle you can move on its own.

The single-file export with assets inlined — the one to send a client with nothing hosted — is still to come.