
:root {
  --design-wireframe-band-height: 150px;
}

*, *::before, *::after { box-sizing: border-box; }

body {
  margin: 0;
  font-family: "Segoe UI", "San Francisco", "Roboto", "Ubuntu", "Cantarell", "Noto Sans", sans-serif;
  background-color: var(--bg-dark);
  color: var(--text-dark);
  display: flex;
  flex-direction: column;
  min-height: 100vh;
  transition: background-color 0.3s ease, color 0.3s ease;
}

/* A link, in the blue of whichever theme is on, and this is the only element on the page that needs
   telling. Everything else inherits its colour from the body rule above ; a link does not, because
   the browser paints one itself, with a value of its own that no theme of ours is consulted about.
   So a site that says nothing here has links in that value on both themes - which is right on a
   white page and, read on this site's own dark card, is 1.5 to 1.

   It sits with the body's own colour rather than in the palette file, because it is the same
   decision : what colour ordinary text is, per theme. The palette file holds the two values and no
   rule at all.

   Deliberately the bare element and not a class. Everywhere this site wants a different link -
   the navigation entries, the search bar, a design's name in the gallery - already says so with a
   selector naming a class, and each of those outranks this one, so this reaches exactly the links
   nobody has decided anything about. Those are the ones in sentences, and they are the ones that
   were unreadable.

   Followed links and hovered links have declarations of their own further down, so this one answers
   for the ordinary state alone. The browser's own second colour for a followed link - a dark purple,
   equally chosen for a white page - never arrives on either, because anything a stylesheet of ours
   says beats anything the browser says whatever the selector. */
a {
  color: var(--link-dark);
}

/* Light mode overrides */
body.light-mode {
  background-color: var(--bg-light);
  color: var(--text-light);
}

/* The light half of the link colour, and the reason the theme class is wrapped is a measured one
   rather than a flourish.

   Written the ordinary way - `body.light-mode a` - this rule carries two classes and an element,
   which outranks anything on this site that gives a link a colour with a single class. There is one
   such rule : the sign-in control in the topbar asks to be drawn in whatever colour the text around
   it is. Measured in a browser, the ordinary spelling broke exactly that control and only on the
   light theme, where it went from the topbar's near-black to this link blue while staying correct on
   the dark theme, because the dark half of the pair names no class at all and loses to it. That is
   the same shape of failure as the sentence this file's neighbours describe : right on one theme,
   wrong on the other, and nothing anywhere reports it.

   Wrapping the class means this rule counts for exactly as much as the one above it - a single
   element - so the pair wins together or loses together, and anything that has decided what colour
   a link is goes on deciding it on both themes. Being written later is what settles the tie between
   the two halves. */
:where(body.light-mode) a {
  color: var(--link-light);
}

/* A followed link, and a link under the pointer. Both halves of both states are wrapped in `:where`
   for the same reason the light half above is, and here it is doing more work than it looks.

   Written the ordinary way, `a:visited` carries an element and a pseudo-class - which outranks any
   rule naming a single class, and the sign-in control in the topbar is exactly such a rule. So the
   plain spelling would break that control all over again the moment somebody had followed it once,
   on both themes this time, and only for people who had been there before. That is the worst version
   of the failure this file's neighbours describe : correct on a fresh browser, wrong for everybody
   who has actually used the site, and invisible to anybody testing in a private window.

   Wrapped, every one of these weighs a single element, exactly like the two above. Which means the
   order they are written in is the whole of what decides between them, and it is deliberate : the
   general state first, then its light half, then the followed state and its light half, then the
   pointer last of all. Last wins among equals, so hovering a link somebody has already followed
   shows the pointer colour rather than the followed one - which is the way round a reader expects,
   because the pointer is answering something they are doing now. */
a:where(:visited) {
  color: var(--link-visited-dark);
}

:where(body.light-mode) a:where(:visited) {
  color: var(--link-visited-light);
}

a:where(:hover, :focus) {
  color: var(--link-hover-dark);
}

:where(body.light-mode) a:where(:hover, :focus) {
  color: var(--link-hover-light);
}
