appearance – ./blog.sh https://blogsh.app/tag/appearance/ Posts tagged appearance on Daniel Šnor's personal site. en Sat, 19 Sep 2026 09:49:45 +0200 Whoever loads last wins https://blogsh.app/posts/2026/whoever-loads-last-wins/ https://blogsh.app/posts/2026/whoever-loads-last-wins/ Sat, 19 Sep 2026 09:49:45 +0200 Two real sites wear a look this engine never shipped. sh.cynicky.blog is dressed as Ghost — a full-width lead card, a dotted frame, tiles instead of a plain list. arch-linux.cz is dressed as a Hugo theme, Blowfish specifically — a compact bar, a profile block, cards laid out like someone else's homepage entirely. Neither forked the engine. Neither edited a template. Both still take a plain git pull.

One stylesheet, loaded last

site.extra_css in config/site.yml names a path, or a list of them, loaded after the engine's own colors.css and site.css. That's the entire mechanism — a skin is one file of yours that repaints what's already on the page, and the engine never writes to it, so an update can never conflict with it.

Local paths only: every page carries style-src 'self', and a stylesheet on another host would just be dropped by the browser with no error anyone would ever see — the build refuses a remote path out loud instead, before that silence has a chance to happen.

Whether that file belongs in git is a separate decision — commit it and a second machine already has your look, exclude it and a public repository never carries a design that wasn't meant to be public. The engine's own .gitignore doesn't decide this for you either way.

The rule everything else follows from

Loading last means your rules win at equal specificity — including the rules the engine wrote for narrow screens, which is not the part anyone expects to be winning against.

sh.cynicky.blog's skin floats a table of contents beside the article and gave it a percentage width to match its own measure. On a desktop that looked right. Below 700px, the engine has its own reflow: the contents drop above the text and the width rule becomes auto, because there's no room beside anything at that size any more. The skin's percentage didn't know that and kept applying anyway — loading last means winning always, not just when it's convenient to. The article came out 155 pixels wide on a 390-pixel phone screen.

The fix wraps the override in the range where it's actually meant to apply:

@media (min-width: 861px) {
  .toc { width: 350px; }
}

Below that width, the skin says nothing, and the engine's own reflow is left to do the one job it was already doing correctly.

What the engine leans on without saying so

Two smaller traps came out of the other skin, arch-linux.cz's, and both share the same shape: a rule that looks purely decorative turns out to be load-bearing somewhere else.

Unsticking the engine's nav bar is a reasonable thing for a skin to want. On arch-linux.cz it also made the theme-switch button stop responding to clicks — not because the button broke, but because the bar sat in a CSS grid, where z-index takes effect without needing position at all, and the unstuck bar kept its higher layer sitting invisibly on top of the button. The site's own admin found it by actually clicking the switch; nothing in a screenshot would ever have shown it.

A second, smaller one: max-width on a flex item with flex-basis: 100% shrinks the item's hypothetical width rather than capping its contents — which is how an article body once ended up sitting beside its own meta line instead of below it. The cap belongs on the children, not the box around them.

One page of a listing, not the whole feed

A stylesheet can't read an address, so the front page and /page/2/ used to be indistinguishable to CSS — which mattered the moment either skin wanted a lead card on the first page only. Since 1.3.2 every listing's <body> says which kind it is:

.page-first .post-list-item:first-child { /* the lead card */ }
.page-cont  .archive-note { /* only on the continuations */ }

Two classes rather than one, on purpose — a single mark on the continuations would mean writing the first page's look unconditionally and then undoing it property by property, and a rule that undoes another rule is the kind a later edit quietly stops undoing.

sh.cynicky.blog

That's sh.cynicky.blog above — full-width lead card, dotted frame, tiles instead of a plain list, and not one edited engine file behind any of it. Its search stays a field in the engine's own bar rather than the modal Ghost itself would give it, because rebuilding it as one would mean owning behaviour the engine never promised. Neither skin, this one or arch-linux.cz's, ever tried for a pixel-perfect copy of what it imitates. Fidelity was never the goal. Belonging to the family was.

A skin stops being the cheap tool the moment it needs markup the engine doesn't build — at that point editing the template is the honest choice, not a stylesheet fighting to fake one. Short of that line, though, none of this needed a theme system: no hooks, no registry, no hierarchy of overrides to keep straight. One fact carries the whole feature. Your file loads last.

—

P.S. — sh.cynicky.blog isn't where cynicky.blog itself lives. The real site is still on Ghost, updated most days; sh.cynicky.blog is the same look, kept as a working installation of its own. Its author looked at a real migration and chose to stay where he already was — worth saying plainly, rather than letting a domain name imply otherwise.

]]> appearancephilosophy One line of colour https://blogsh.app/posts/2026/one-line-of-colour/ https://blogsh.app/posts/2026/one-line-of-colour/ Tue, 08 Sep 2026 16:22:00 +0200 A reader changed one border colour in site.css, ran a rebuild, and waited while the build produced, byte for byte, every page that was already there. He asked why. The answer was one word in one list, and 1.7 takes it out.

What a build writes down

Since 1.6 the build keeps a record of what went into each page it wrote -- the post, the posts around it, the labels, the numbers a page counts. On the next build a page whose record has not moved is not rendered at all. Not rendered and then found identical: not rendered. The summary at the end says how many pages were left alone, the first number to look at when a build is slow.

The record holds only while the engine that wrote it is the same engine, so it hangs off a fingerprint of what the engine is made of -- the files under templates/, lib/, build/, locales/ and config/, hashed by contents rather than by timestamp. Change any of it and the record is discarded entire, because any of it can change every page.

Why the colour cost the archive

Until 1.7 that list also had assets/ on it, and assets/ is where the stylesheets live.

A page does not contain its stylesheet. It carries a <link> to one, and there is no ?v= on that link -- a version baked into the URL would make every page differ on every CSS edit, the same problem wearing a different coat. So the bytes of a rendered page cannot move when site.css moves. The fingerprint was covering a file no page has ever held.

Measured in a copy of the engine, on a test site of 270 posts: a rebuild that changes nothing skips all 378 pages the cache is asked about, and adding a rule to site.css still skips 378. Put assets back into the fingerprint -- the 1.6 behaviour -- and the same edit skips none.

Nothing is given up. Files under assets/ are compared with their published copies on every build, by a path that never consulted this record. The edit reaches the site as it always did, and now costs that one file and nothing else.

What is still fingerprinted, and what that costs

config/ stayed on the list, and the palette is one reason it had to.

The colours in config/site.yml are not read out of a stylesheet. They generate one -- assets/css/colors.css is written by the build, not copied from the tree -- and one of them reaches the pages a second way: the light and dark theme-color in the head of every page the layout renders is the palette's background. Change bg and every one of those pages really is different. Rebuilding them is the record being right.

Change accent and no page moves. It lives only in the generated stylesheet, and the site is rebuilt all the same: the fingerprint is taken over whole trees rather than the keys inside them, so config/site.yml moving throws config/ away. On the same test site that edit skipped nothing and rendered all 378. It is the cost this release took off assets/, kept on purpose in a smaller place -- a tree is a coarse thing to hash, and coarse errs towards work. A tree belongs in the fingerprint when a page can hold its contents; linking is not holding.

When the record is not believed

  • The first build after an upgrade. This release changed lib/build_cache.rb, and lib/ is in the fingerprint, so the first build on 1.7 renders everything. An engine that worked out which pages a template edit reaches would be wrong eventually, and wrong here means a live site serving stale markup with nothing saying so.
  • The facts the build hands to the record by name rather than by hashing a tree: the menu, which content types the archive holds, the address it is published at, and the timezone -- named by the contents of its zoneinfo file, so a system update that rewrites the rules of your zone throws the record away rather than leaving old times on skipped pages.
  • Any page whose published file has been deleted, or has moved in size or timestamp since the build wrote it. The record is checked against what is on disk, never only against itself.
  • A record that is missing, half-written or unreadable. Deleting .build_cache.json is always safe and costs one slow build.
  • A build that died halfway. It writes no record at all, because a record of a site half written would make the next build skip the half that never got written.

./blog.sh rebuild --full is the switch for the rest: render everything, compare everything, believe nothing. It is the escape hatch, and it is how the record is tested: a cached build and a full build over the same content must produce byte-identical trees.

What it costs

With no version in its URL, getting a changed stylesheet to a reader is the host's job: it works where files carry an ETag and are revalidated on each load, and a host that caches hard will serve the old one until it expires. And backdating is untouched by this: a post dated 2003 shifts every listing page between the front and where it lands, and those pages really did change.

]]> buildappearance A bicycle nobody had to draw https://blogsh.app/posts/2026/a-bicycle-nobody-had-to-draw/ https://blogsh.app/posts/2026/a-bicycle-nobody-had-to-draw/ Mon, 07 Sep 2026 16:12:00 +0200 The example configuration this engine ships carries a bicycle: a tag called kolo, and under it an <svg> written out by hand. It is there because there was nothing else to put there. tag_icons took the name of an icon the engine ships or a drawing of your own, and the ones it shipped were the eight content types — text, image, video, link, audio, quote, document, chat. A tag about cycling could wear the glyph for "audio", or somebody could spend an evening with a coordinate grid.

1.7 puts fifty-five drawings in between, and gives each of them a name.

Fifty-five nouns

Counted in lib/icons.rb: the eight content types, fifty-five more, sixty-three names a tag may ask for. Grouped by what a blog turns out to be about.

A sheet of the fifty-five drawings, each with its name
The whole set, by name. Drawn on the same grid and stroke as the eight the engine has always shipped.
  • getting about — bike car train plane boat walk
  • places and weather — map pin mountain tree sun cloud rain snow
  • a day — coffee beer food wine clock calendar home heart star gift
  • making things — pen brush camera film mic music book tools hammer
  • machines — laptop phone code terminal server bug lock key
  • living things — paw bird leaf flower
  • ideas — bulb flag globe eye chart target rocket mail briefcase box

Plain English, and the word somebody reaches for first: bike, not bicycle. A footer link under social: can wear one too, where the network marks have nothing to offer: globe for somebody's other site.

Why they sit beside the eight

The same 24-unit grid, the same two-unit stroke, the same currentColor — the part that lets one drawing follow a light theme and a dark one without a second copy. All fifty-five carry round ends and round joins, because they are pictures of things rather than diagrams and a mitred corner on a two-unit stroke reads as a spike at twenty pixels. doctor holds a hand-written icon_svg to that same grid.

Where it turns up

Two places. The heading of the tag's own /tag/<name>/ listing, and the date badge of every post carrying that tag — where it replaces the content type's icon rather than joining it. A badge is a small tile with a date and one glyph; the only thing that ever adds a second is a pinned post, and a listing stacks ten badges under each other.

A tag is matched by its address rather than its spelling. Sci Fi in site.yml reaches posts tagged sci-fi and posts tagged sci_fi, because those are one page and therefore one tag.

The order in the list is the priority

tag_icons is a list, and the order in it decides. Most posts carry more than one tag, and the tag a post was given first is usually whatever an importer put there rather than a subject — so the first entry in the list that a post has is the one it wears, settled once instead of post by post. A post tagged sci-fi, coffee wears coffee if coffee stands higher, whatever order the post wrote them in.

Written as a mapping — kolo: bike indented underneath, the shape half of site.yml is in — it draws nothing, and it always did: until now with no warning from the build, and doctor calling the file sound. Both name the key now, and doctor counts it a problem and exits 1.

What it refuses to do

It is not a folder to drop drawings into. Everything under assets/ is copied onto the site wholesale, so a folder of fifty would publish fifty files to serve a site that uses two — and an icon is written into the page rather than fetched, so nothing would ever ask for them. The set is a Ruby hash for that reason.

The eight content names cannot grow without a content type behind them. And an icon_svg that is not a drawing at all — a filename, an address, an emoji — is refused rather than printed where the glyph goes; the tag falls back to what it would have had with no entry.

What it costs

A name the engine does not have draws nothing, and the build does not mention it: configure bicycle instead of bike and the site builds, exits zero, and every post that should have carried a bicycle keeps its content type's icon. doctor is what says so: it names the tag, the name it asked for, and prints all sixty-three, eight to a row — then exits zero itself, because a tag without a picture is not a broken site.

And the drawing goes into the page. The middling one is a shade over 250 bytes of markup, written out again for every badge that wears it: no request for it, and no way to have it once. The whole set comes to about fifteen kilobytes, and none of it reaches the site — only the drawings actually used.

Most of the drawings in that file are this project's own. Several are the shape any icon set converges on for an obvious thing — the pen, the spanner, the speech bubble on a chat post — and those are the same paths as Feather Icons, MIT licensed, copyright Cole Bemis. NOTICE says so and carries the licence, which is what a repository owes the people it borrowed from.

]]> appearancecontentrelease A badge that says what a post is about https://blogsh.app/posts/2026/a-badge-that-says-what-a-post-is/ https://blogsh.app/posts/2026/a-badge-that-says-what-a-post-is/ Sat, 05 Sep 2026 11:06:00 +0200 Every post wears a date badge with an icon in it, and the icon says what kind of post it is: text, a picture, a video, a quote. On a blog where nearly everything is text, that icon is the same on nearly every card. Somebody running this engine put it plainly in issue #45: one sees the generic icon so often that it becomes invisible, or clutter.

1.6 lets a tag carry an icon instead.

tag_icons:
  - tag: "build"
    icon_svg: '<svg viewBox="0 0 24 24" …>…</svg>'
  - tag: "comments"
    icon: "chat"

It replaces rather than adds

On a post's date badge the tag's icon takes the place of the content-type icon; in the heading of /tag/<name>/ it takes the place of the generic tag icon. That was the requester's first point, and the one worth asking about rather than guessing: two icons side by side on a 60-pixel badge is not a badge, it is a puzzle. A tag with no entry changes nothing, so the generic icon is still there for everything you have not named.

The order is the priority

Most posts carry more than one tag — 68% of them on the archive this was measured against — so tag_icons is a list, and the first entry a post matches is the one it wears. That rule was chosen because the tag a post was given first is usually an importer's rather than a subject: twitter alone opens 1,256 posts on that archive. The order in your config is your order, not the post's.

Eight by name, or your own

icon names one of the eight the engine ships — text, quote, chat, image, video, audio, link, document. icon_svg is yours: drawn on the same 24-unit grid, stroked in currentColor so it follows the light and dark themes, with scripts, styles and event handlers stripped before it reaches a page. doctor checks every entry: whether the name is one the engine has, whether a hand-written SVG contains an <svg> at all, and whether it is drawn to the same scale as the rest. An unknown name used to draw an empty space and say nothing.

On this site, since today

The seven tags in this site's menu have icons now — a bulb for Why, a pen for Writing, a box for Archive, a spanner for Engine, the engine's own chat icon for Comments, an eye for Looks, a package for Releases. Look at the badge on the left of this post, then at the badges on the front page, and you will see the rule at work: a post tagged appearance, content wears the eye, because appearance is named and content is not.

The whole thing was asked for by one person, shaped by his three points, and shipped with the request still open so he could say where it was wrong. He did not have to.

]]> appearancecontent Where a reader carries a post https://blogsh.app/posts/2026/where-a-reader-carries-a-post/ https://blogsh.app/posts/2026/where-a-reader-carries-a-post/ Fri, 04 Sep 2026 16:52:00 +0200 A post gets read, and then it goes somewhere: into a toot, a message, an email to one person. Until now the reader did that by copying the address out of the bar. 1.6 puts a row of controls under the post for it — off unless share: names what you want, drawn in the order you name it.

share:
  - mastodon
  - bluesky
  - email
  - copy
  - system

What is prefilled, and what is not

The post's name and its address, where the target takes both. Facebook and LinkedIn take the address alone and read the name off the page. The reader writes the part that is theirs. bluesky, email, facebook, linkedin, threads and x are plain links, one address each, no script behind them.

The fediverse has as many addresses as it has instances, and a page cannot know which one is the reader's. So mastodon is a button that asks — in a row that opens under the controls, in the site's own type — and remembers the answer in that browser afterwards. Nothing about the reader leaves the page; the instance name is kept where they typed it.

copy puts the address on the clipboard. system hands the post to the operating system's own share sheet, which on a phone is Signal and WhatsApp and Telegram at once, and on a desk is whatever the system offers.

Those three appear only where they can work. A browser without a clipboard API gets no copy button, a desk without a share sheet gets no system button, and a block left with nothing to draw hides itself rather than standing a heading over an empty row.

Why there is no Pixelfed

Pixelfed has no address a page can hand a post to. A button that opened nothing would be worse than none, so there is none, and the changelog says so under "not fixed, on purpose" rather than leaving you to wonder.

One new file

assets/js/share.js is a file every page now loads. On a site that never sets share: it does nothing at all; it is still a file, and a deploy that misses it leaves a 404 in the console. git pull, rebuild, deploy — and it is there.

The controls make no request to anyone until the reader presses one. That is the rule for everything the engine puts on a page, and this row is no exception: the share buttons of the web are usually the one thing on a page that phones home before you touch them, and these do not.

]]> appearancecomments The card that reads Codeberg https://blogsh.app/posts/2026/the-card-that-reads-codeberg/ https://blogsh.app/posts/2026/the-card-that-reads-codeberg/ Wed, 26 Aug 2026 10:31:00 +0200 The sidebar has a commits card. Until now it read GitHub, full stop — which is a strange default for an engine whose natural habitat is the Fediverse, where the code lives on Codeberg or on somebody's own Forgejo, and GitHub is the mirror you keep for one widget's sake.

One of the first people outside this project to run the engine asked the obvious question, and the answer shipped: widgets.commits.instance takes the server's address, and that is the whole configuration.

One key, not two

There is no forge_type beside it. An address already answers what kind of host it is — Gitea and Forgejo speak the same API, and a key that must agree with another key is a config mistake waiting for its moment. Leave instance out and the card reads GitHub, exactly as before.

Cheaper than the original

The forge path costs one request where GitHub costs one per commit, because a Gitea activity item carries the commits it is about — message and timestamp included. A card on your own Forgejo is lighter on your own server than the GitHub card ever was on theirs.

The mistake is caught standing up

An empty commits card is indistinguishable from "has not pushed lately", so doctor checks the address before that ambiguity can start: a pasted @handle or a bare host name is refused with a sentence, and an address with a path after it is flagged as worth checking — with the API endpoint that settles it. ./style.sh asks the new question too, on configs written before this key existed as well.

]]> appearance A skin that survives git pull https://blogsh.app/posts/2026/a-skin-that-survives-git-pull/ https://blogsh.app/posts/2026/a-skin-that-survives-git-pull/ Thu, 20 Aug 2026 16:42:00 +0200 Dressing a site differently used to mean editing a file the engine owns. It worked, right up until the next git pull, which is the moment you find out that customisation and updates were the same file all along.

Four things that needed a modified template are settings now.

Both of these sites are this engine, built from the same commit on the same evening:

blogsh.app, wearing nothing but the defaults
sh.cynicky.blog: a stylesheet of its own, no sidebar, a lead image on every post and a menu it named itself

The second one uses all four of the settings below and not one edited engine file — git status in that installation is empty, which is the entire point of the exercise.

Your own stylesheet

site.extra_css takes a path, or a list of them, loaded after the engine's own. A skin lives in a file of yours and updates never see it.

site:
  extra_css: /assets/css/mine.css

Local paths only. Every page carries style-src 'self', so a stylesheet on another host would be discarded by the browser with no error you would ever notice — the page would simply render undressed. The build refuses it out loud instead, and doctor names the line it had to skip.

Your own menu

Without nav: the bar is derived from the content types that actually have posts, exactly as before. With it, the site says what belongs there:

nav:
  - { label: "Home", url: "/" }
  - { label: "Photographs", tag: "photo" }

An entry missing either half is skipped rather than rendered as an empty link. An empty list is a decision rather than a mistake — the menu then renders nothing at all, which is also how a site turns the menu off, so there is no second key for that.

./style.sh edits it and does the tedious part: it offers your busiest tags and your pages by name, so you pick rather than type slugs. doctor reports an entry whose target has since gone missing, and the url: "about" spelling that works from the front page and nowhere else.

Two regions, on or off

layout.sidebar switches the right-hand column off and lets the content take the full width. layout.hero lifts a post's first usable image out of the text and runs it above the title — off unless you ask, because it reshapes every post page it touches, and a single post can still decide for itself with hero: in its own header. A tracking pixel is never promoted to lead picture.

They are switches for regions, not for how a region looks. What things look like belongs in a stylesheet, and a key per visual property would turn the config into a stylesheet written in YAML.

All of it from the wizard

./style.sh grew a Layout section, so palette, banner, fonts, menu, regions and your own stylesheets are one conversation. A site can now be dressed entirely from the wizard, which was the whole point of making these settings rather than documentation about which template to edit. Entering a section and pressing through it changes nothing.

The one thing that changed without being asked

The menu bar follows you down the page now. It took over the job of the menu that used to be repeated under the content — which only existed because the bar didn't — so that one is gone, key and all. Two copies of the same menu on one screen is not a preference.

The line that menu used to draw above the footer is drawn without it, and anything that scrolls a target into view now stops short of the bar rather than under it.

]]> appearance A palette you can look at first https://blogsh.app/posts/2026/a-palette-you-can-look-at-first/ https://blogsh.app/posts/2026/a-palette-you-can-look-at-first/ Thu, 13 Aug 2026 10:41:00 +0200 An earlier post here explains that every colour on this site comes from seven keys in a config file. That part hasn't changed. What has changed is that you no longer have to imagine what those seven values will look like before you commit to them.

Choosing between fourteen hex values is exactly as blind in a wizard as it is in YAML. So ./style.sh shows you.

Seven palettes, one keystroke

Whole palettes now ship in config/palettes.yml, light and dark both:

  • Default blue, warm, monochrome and high contrast — the four from the gallery on this site, whose light modes are exactly what that page showed. Their dark modes are new; the gallery only ever had light homepages.
  • Sunflower, cream and gold with olive links — the golden yellow stays on the tag pills, because yellow text on cream cannot be read and the accent here is above all a text colour.
  • Garden, greens and khaki.
  • Ocean, steel blue over navy.

Those last three come from the TangerineUI Classic family this engine's own palette grew out of — its bluebird is the default palette here, to the last hex value.

Homepage in the Sunflower palette
Sunflower — cream and gold, olive links
Homepage in the Garden palette
Garden — pale green page, khaki nav, grass-green links
Homepage in the Ocean palette
Ocean — steel blue on cool grey, navy in the dark

Adding your own is adding an entry to that file. The wizard lists whatever it finds, and a palette you add needs no translation to show up.

Then it shows you the site

Pick one — or finish the fourteen-value custom route — and you are offered a preview: your own built site in the candidate colours, light and dark side by side. On a fresh install with nothing to render yet, a bundled sample post goes through the real builder instead.

On a deployed site the preview travels the way a draft preview does. It is uploaded to your own /palette-preview.html, and the wizard answers with the full address and a QR code — so a palette chosen at an SSH prompt can be judged on the phone in your pocket, on the screen people will actually read it on.

A tablet held in one hand shows the palette preview — the same blog in light and dark mode side by side — with the terminal and its QR code on the laptop screen behind.
Chosen at an SSH prompt, judged in the hand

Locally it lands in tmp/palette-preview.html and opens in a browser where there is one.

The colours go through the same code the build uses. That is not a detail: lib/colors_css.rb was extracted for exactly this, so a preview cannot drift from what a rebuild would produce. A preview that lies is worse than no preview.

Nothing is written until the usual confirmation.

The banner section measures for you

Give it the path to an image and it copies the file into place and measures it. banner.width and banner.height exist to reserve layout space before the image loads; they have always been copied by hand, and a stale pair makes every page jump as it loads.

Why this is its own wizard

setup.sh and style.sh both write config/site.yml. They are split by lifecycle, not by file: setup asks the things you answer once, this is everything you come back and fiddle with — palette, banner, about text, footer, social icons, sidebar widgets, fonts, analytics.

So it is a menu you dip into, not a form you complete. Which is the honest shape for the part of a site nobody ever finishes adjusting.

]]> appearance Seven keys https://blogsh.app/posts/2026/seven-keys/ https://blogsh.app/posts/2026/seven-keys/ Fri, 31 Jul 2026 22:17:29 +0000 There is not a single colour value in this site's stylesheet.

Every colour you're looking at right now — background, text, links, the navigation, the little tag pills — comes from seven keys in config/site.yml. The build compiles them into a colors.css file, and site.css just uses the variables. Change seven lines, rebuild, and the site is someone else entirely.

Here's a complete light-mode palette:

colors:
  light:
    bg: "#f5f8fa"
    text: "#444a5a"
    meta_text: "#657784"
    accent: "#1da1f2"
    nav_bg: "#eaf5fd"
    border: "#e1e8ed"
    pill_bg: "#d6ecfc"

And here's the same homepage in five palettes — nothing changed between these shots except seven lines of YAML and a rebuild:

Homepage in the default blue palette
Default blue — the palette this site ships with
Homepage in a warm cream and terracotta palette
Warm — cream, brown, terracotta accent
Homepage in a monochrome palette
Monochrome — the accent is just a darker grey
Homepage in a high-contrast palette
High contrast — black on white, hypertext blue
Homepage in a deliberately hideous palette
Deliberately hideous — lime, purple, magenta, orange

The hideous one is the proof, by the way: if the config can make it that ugly, the config really is in charge.

What you don't configure

Everything else is derived: card backgrounds, link hover states, the search field, code block backgrounds. Those aren't extra config keys, because in practice they never varied independently — every time I tried a palette, the derived values followed the base ones anyway. Seven keys per mode is the honest number of decisions involved.

Dark mode is the same seven keys again, so light and dark are two palettes, not one palette and a filter.

Two exceptions, on purpose

The banner can optionally override its title and claim colours — banner_title and banner_claim — because a banner is an image, and text sitting on an image plays by different rules than text on a flat background.

And one small thing I like too much not to mention: the scrim that keeps banner text readable only darkens the corner the text actually sits in. Turn the overlays off and your banner stays exactly as you drew it, corner to corner.

]]> appearance