Demo Overview
This is the front page of the demo folder. Every demo page is linked from here, in the page body – not through the menu. Open any of them to see one module, or a whole page composition, in action.
This is the front page of the demo folder. Every demo page is linked from here, in the page body – not through the menu. Open any of them to see one module, or a whole page composition, in action.
Most templates require the content to fit their shapes. Headings must not get too long, card titles must not run to two lines, paragraphs must not be too short. Anyone who maintains text knows the result: you write for the layout instead of for the reader.
This template turns that around. The content is fixed, the layout adapts. Text can be changed, lengthened, shortened or swapped at any time without anyone touching the layout. Nothing overlaps, nothing is cut off, nothing collapses.
Common systems ask: how wide is the window? This one asks: how much space do I have here?
That is a difference with consequences. A component behaves just as correctly in a narrow column as it does across the full page – it decides for itself when to wrap, because it knows its own space. You can nest modules inside one another without thinking about screen sizes. With window-based systems, an element in the side column only wraps once the whole window becomes narrow – that is, too late.
The site header carries four parts: the branding, an optional addition, the menu and the fullscreen button. Instead of throwing everything into the collapsible menu at the first pinch, it scales down in four steps – from wide to narrow, only the part that needs space last is dropped:
The breakpoints are measured against the actual content of the site header, not estimated. An included check script recomputes them whenever anything in the site header content changes, and reports when a value stored in the stylesheet is no longer correct.
Equal-width columns from two to six. They wrap as soon as a column would get too narrow – and they never become more than the intended number. Four cards stay four cards, even on a wide monitor.
Ratio rows for unequal splits. One third to two thirds, one quarter to three quarters, three columns with a wide one in the middle – the usual splits for text next to image, content next to sidebar, feature next to extras.
Self-determined order when stacking. When a row stacks vertically, you decide what goes on top – regardless of how it appears in the source. On the phone the image first, at the desk the text first: one setting, not a second blueprint.
Breakouts across the full window width. A single column can break out of the page width and take up the whole screen without leaving its row. Edge-to-edge images, full-bleed colored sections and screen-filling features are created in place this way, instead of breaking through the page structure.
In a card grid, the image, category, title and excerpt of all cards align with one another – even when one title runs to two lines and the next to one. No truncating of titles, no rule for the editors on how long something may be, and yet a calm grid line.
This is the point where most card grids either look restless or shorten the text. Here neither one happens.
The typography grows continuously with the window width. There are no points at which the type suddenly jumps – when rotating a tablet, when dragging the window, when moving from the laptop to the large monitor, the text stays calm.
The fonts are included and loaded locally. No call to third-party servers, and the fallback font is tuned so that nothing shifts when the real font loads in.
A page is built from building blocks: feature, article text, card grid, image grid, post list. Each building block is its own file and does not know where it sits. That is why it works everywhere – in a narrow column, across the full page, several times on one page, inside another module.
New building blocks are created along a fixed path: first the profile, which describes what the module can do and which fields it has, then the markup. This lets the template grow without becoming inconsistent.
Colors, fonts, size steps and spacing are collected in one place. A different color scheme is a handful of changed lines, not a search through the whole file. Anyone building several websites uses the same building blocks with different values – and gets sites that differ without anything having to be rebuilt.
The HTML holds content, not styling instructions. A few, meaningful class names instead of long chains of abbreviations. You can open a page and read what is on it – even after a year, even if someone else wrote it.
This is at the same time the prerequisite for the template to be transferred later: into a WordPress theme, an Astro site, another system. Nothing has to be removed first.
No build step. No dependencies. No package management, no compiler, no version conflicts. You open a file in the browser and see the page – today as in five years.
JavaScript never carries the layout. It toggles fullscreen mode, remembers the state of the collapsible menu, switches dark mode and reveals the back-to-top button. If it fails, the page stays usable; the site header also scales down through all four steps without JavaScript, only opening the menu overlay needs it.
Included are checks that run before every save and before every transfer: whether building blocks use the defined colors, fonts and sizes, whether the page alignment is correct, whether a module matches its description.
This sounds like small stuff and is the reason a template stays consistent over months instead of slowly drifting apart.
| Usual class frameworks | Classless libraries | This template | |
|---|---|---|---|
| What does the wrap depend on? | on the window width | not at all, no layout | on the space at the component's location |
| Unequal column ratios | partly, via number classes in the markup | no | yes, named and ready |
| Order when stacking | source order | – | freely determinable |
| Breakout to full window width | special solution per case | no | built in |
| Cards lined up | only with equally long text | – | always |
| How does the HTML read? | styling in the markup | very clean | clean, with named building blocks |
| Build step needed? | mostly yes | no | no |
| Adjust the appearance | learn a custom theme system | predefined, bending it costs | values in one place |
Classless libraries style elements – headings, paragraphs, tables – and leave the page structure open. Class frameworks solve the page structure, but in return require the styling to move into the markup and the wrap to depend on the window width. This template closes the gap in between: page structure as named building blocks, styling in the stylesheet, wrapping where it actually happens.
Content-driven websites: magazines, blogs, portfolios, agency and company sites – everywhere that text and images change regularly and no one wants to redo the layout after every change.
It is less suited to application interfaces with many states and controls. There are component libraries for that; this template is for pages that are read.