Section 4: The Design System — Figma Export, Clean WordPress, and the Class System

Two image species exist: pixel (PNG/JPEG — anything shot on a camera) and vector (SVG — anything born digital: icons, illustrations, logos, background blobs, blurs). Vectors stay sharp at any zoom and weigh kilobytes; pixels degrade and weigh hundreds. So the rule: 'when you can use vector... then do it.' Within pixels, PNG only when the image has transparency (cut-outs, rounded corners); otherwise JPEG — more colors, better compression.

The second lever is shadows: exporting a box WITH its drop shadow bakes the shadow into the bitmap and ballooned the demo file 8–9× (23KB vs 180KB). Strip shadows in Figma (or disable 'include bounding box'), export clean, re-add the shadow in Elementor where it's generated code. Third lever: compression and resize — 'destroying the image quality to reduce file size,' targeted at under 300KB for heroes and under 100KB for small images, with a 2× export for retina and a resize pass (a 3000px blog image survives at 25%).

A fresh WordPress arrives pre-cluttered by the host; step one is deletion. Every stock plugin goes (caching gets DEACTIVATED, not deleted — off during development because dev needs every save visible, back on at launch). Default themes get deleted, not just ignored: an unused, un-updated theme is an attack surface, and one hacked a site of his. The theme decision is permanent: Hello Elementor for every site — 'I never needed another theme,' and if a project demands something beyond it, 'I will just reject the project. It's a form of self protection.'

The plugin stack is five items: Elementor (+ Pro via zip from the account page), Classic Editor (the 5-million-install verdict on Gutenberg), ACF ('only when you know that your website will not need anything dynamic... you can skip' — he never skips), ManageWP Worker (one dashboard for every client site, passwordless login via connection key, free monthly backups), and Admin & Site Enhancements — the one plugin that replaces many: page duplication, media replacement, admin-menu reordering, dashboard-widget cleanup, admin-bar cleanup, a renamed login URL, and login-attempt limits.

Unmanaged palettes sprawl ('you don't even remember where you used those colors'), so the method caps most sites at ~8 colors: headings dark, body dark (deliberately LIGHTER than headings — 'otherwise it's too harsh'), accent, accent hover, then light/light-darker backgrounds and their dark counterparts — about 5 background colors max. Many one-color sites need only the top 6.

The trick is the hijack: Elementor's four SYSTEM colors are pre-wired to defaults across the site, so instead of adding parallel custom colors, he repurposes the slots — primary becomes 'dark darker headings,' secondary becomes 'accent hover,' text becomes 'dark body,' accent stays accent. Renamed and recolored, every pre-wired connection propagates automatically. Custom colors (light, light darker, dark backgrounds) get added below and connected manually in the style guide. Buttons get their background from accent in site settings; links get accent hover ('accent is a little bit too light for links'); and if the site's base background isn't white, that's set globally too.

rem first: 1rem = the browser's base font size (16px by default), so 4rem = 64px. The point isn't the arithmetic — it's WHO controls the base. A user who sets their browser fonts to Large moves the base to ~20px, and every rem-sized element scales with them; pixel-sized elements ignore them. 'For accessibility, it's better to use rem' — and the same logic extends to padding (5rem top/bottom scales with the user too, keeping the design balanced).

clamp second: instead of setting sizes at every breakpoint (which SNAP at each switch), one clamp expression scales a font fluidly from its desktop size to its mobile size — 64px flowing down to 48px as the window narrows. He doesn't hand-write the math ('I don't understand how this calculation works yet, but I don't need to') — the Font Clamp generator website does it, configured 360→1120. Headings scale; body text doesn't ('16 pixels... on mobile it also looks good'). Line heights are percentages so they scale with whatever the font does: 180% body, 120% titles.

The third principle is separation of concerns: H1–H6 are SEO signals ('Google sees this as the most important title'), so sizes live in custom global fonts (Title 1–7, Body, Body Bold...) and the HTML tag gets chosen for meaning — 'you can still make this an h4 and it doesn't influence the size.'

Padding classes: a snippet defines pad-s / pad-m / pad-l (plus pad-top/pad-bottom variants), each a clamp expression so the padding scales desktop→mobile automatically. Usage is typing the class into a container's Advanced tab — no per-breakpoint values, globally editable by changing the snippet. The discipline from the export audit pays off here: three sizes only, 'you don't wanna have too many sizes.'

Button classes: the second snippet defines button-dark, button-light, button-outline-light, button-accent-2 — and wires their colors to Elementor's own CSS variables. The trick: inspect any global color in DevTools, copy its --e-global-color-xxxx variable, paste it into the snippet — now the buttons follow palette changes dynamically ('you can use the hex code... but then it's not dynamic'). One global rule adds the hover for ALL buttons — a 0.4s transition, 7px x-shift, and a brightness filter — replacing per-button hover setup entirely. It even works on widgets' embedded buttons (forms, popups).

The snippets live in Appearance → Customize ('the best place to place your CSS'), and he flags the whole system honestly as a stopgap: 'I heard they are working on a classes feature. Right now, they don't have it, so we still have to use code.'

His style guide is a saved template (imported as JSON into Elementor's saved templates) holding every element the system defines: colors on light and dark backgrounds, all title sizes with two-row text (so line height is visible), buttons in every class, boxes-on-backgrounds contrast pairs, and sections wearing each padding class. Freshly imported, nothing is connected — the horror show is intentional, because 'the whole goal of a style guide is to check if your design is consistent.' As colors, fonts, and classes get wired up across the chapter, the guide becomes the single page where the system proves itself — resizable in a real tab, so clamp scaling and responsive padding can be watched live (Elementor's built-in style guide preview can't resize, doesn't show sizes, buttons, or padding).

Version 2 (the Reno-from-the-future lesson) trims what Elementor caught up on: the color palette section is gone because the improved native panel now click-scrolls with live editing, while typography stays (two-row line-height checks, window-resize scaling) and the class checks deepen — every section wears a DIFFERENT pad class, and boxes now sit on every background 'because what I realized when I was designing websites is that often you have boxes on top of backgrounds.'