Teaching an old dog new tricks

Reset Style Sheets

ol, ul {
  list-style: none;
}

There used to be a time, when reset style sheets were really useful because the browser landscape was more diverse than today and browsers rendered pages very differently by default. Eric Meyer famously created the first popular reset style sheet, reset.css, which did things like removing margins, paddings and border, and resetting other properties.

html {
  cursor: default; 
  overflow-y: scroll; 
  -webkit-tap-highlight-color: transparent;
  -webkit-text-size-adjust: none;
}

normalize.css by Nicolas Gallagher Nicolas Gallagher took a gentler approach and normalised more than reseted. That made sense and was super useful.

The thing is, that was a long time ago and both style sheets solved many problems that don’t exist anymore today, but reset style sheets are still a thing. There are modern style sheets, like for example “The New CSS Reset” by Elad Shechter.

*:where(:not(html, iframe, canvas, img, svg, video, audio):not(svg *, symbol *)) {
    all: unset;
    display: revert;
}

His approach is to reset almost everything. He selects most of the elements and sets all: unset and you can also see a lot of none and revert keywords. That’s pretty radical, but there are also other modern style sheets that take a different approach.

body {
  min-height: 100vh;
  line-height: 1.5;
}

For example, Andy Bell’s “A (more) Modern CSS Reset”. Looking at it and other similar style sheets, I realised that today it’s more about improving the defaults rather than resetting or normalising properties.

So, this is the first area where I’m challenging my usual approach. I’m trying to find out if maybe it makes sense to use a reset style sheet in 2025 and if modern CSS can solve problems that I may have.

*, * after, * before { 
  box-sizing: border-box; 
}

Of course, in my reset style sheet I’m doing some of the basic and well established stuff, like using the traditional box model, but now we are mostly interested in the new CSS stuff.

:where(label):has(

:where(input:not([type=”radio”], [type=”checkbox”]), select, textarea) ) { display: block; }


If you create a label and an input field, by default, this is how it looks like in the browser. The input field is next to the label. I would say in 98% of cases that's not what you want because we know that for the UX it's best to put your input fields below the label. That's what this rule does. I'm saying every label that is followed by an input, select or textarea, sets display block. Of course, that doesn't apply for radio buttons and check boxes.

:where(dialog),
:where(dialog)::backdrop {
  opacity: 0;
  transition: opacity 300ms ease-out, 
              display 300ms allow-discrete,
              overlay 300ms allow-discrete;
}

Here’s another example: By default, if you open a dialogue, it just appears and disappears and there is no transition. The problem is that the dialog is hidden and we can’t animate hidden elements, or at least we weren’t able to do that for the longest time. Today, it’s possible by not just transitioning the opacity property but also the display property with the allow-discrete keyword, which allows the animation or transition of discrete properties. The same goes for the overlay property which allows us to fade out the backdrop of the dialogue.

:where(dialog),
:where(dialog)::backdrop {
  opacity: 0;
  transition: opacity 300ms ease-out, 
              display 300ms allow-discrete,
              overlay 300ms allow-discrete;
}

:where(dialog[open]),
:where(dialog[open])::backdrop { opacity: 1; }

@starting-style {
  :where(dialog[open]),
  :where(dialog[open])::backdrop { opacity: 0; }
}

To allow our dialogue to fade in as well, we have to define a starting style and set opacity: 0.

Structure and Organisation

ITCSS by Harry Roberts

/* Establish the order of layers upfront */
@layer core, third-party, components, utility;
@layer core.reset, core.tokens, core.base;
@layer third-party.imports, third-party.overrides;
@layer components.base, components.variations;

Luckily, now we have cascade layers that allow us to enforce these rules. Layers defined later in the document overwrite layers defined earlier. For my project, I didn’t just want to use cascade layers. I wanted to come up with a structure that I can use in any project of any size. Here is what it looks like. We have four main layers: core, third-party, components, and utility. base consists of three sub layers. One for reset style sheets, one for tokens, and one for base rules. The third-party layer consists of two sub layers. One for imports, so that’s where your bootstrap.css or prism.css belongs, and one for overrides. If there’s anything that you want to change in these third-party styles, you don’t do it just anywhere, you do it here so there is one dedicated place for it. The component layer consists of two layers, one for the base and one for variations. * / Establish the order of layers upfront

/* Establish the order of layers upfront */
@layer core, third-party, components, utility;
@layer core.reset, core.tokens, core.base;
@layer third-party.imports, third-party.overrides;
@layer components.base, components.variations;

/* Reset, normalize, etc. */
@import url('uaplus.css') layer(core.reset);

Here is how I add my reset style sheet by using the @import at-rule and importing directly into the core reset layer.

/* utilities.css */

@layer utility {
  .visually-hidden {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
  }
}

Here’s how I add a utility class to the utility layer.

/* components/card.css */

@layer components {
  @layer base {
    .card {
      --size: 20rem;
      max-inline-size: var(--size);
    }
  }

  @layer variations {
    .card-large {
      --size: 30rem;
    }
  }
}

Here’s an example for component style.

@layer core, third party, components, utility;

What’s great about that is that it doesn’t just make working with the Cascade easier, it also allows me to split up my CSS into multiple files and not having to worry about specificity because in the very first line we have already established the order of the cascade layers. If we use them later on anywhere in the documents, we’re not redefining layers we’re just reusing them.

Scalability

h1, h2, h3, h4, h5, h6 { 
  text wrap: balance; 
}

I’m selecting all headings and I’m using text-wrap: balance. This ensures more balanced line lengths in multiline headings.

h1 {
  font-size: 47px;
}

h2 {
  font-size: 41px;
}

h3 {
  font-size: 30px;
}
…

When I work with headings, I usually take the font sizes from the design and put them in my CSS. That’s fine, but these sizes are just by looking at the CSS random numbers.

h1 {
  font-size: 51px;
}

h2 {
  font-size: 40px;
}

h3 {
  font-size: 32px;
}
…

Instead of random numbers in my style sheet, I now use the numbers from the type scale, but looking at the CSS these numbers are still magic numbers. They don’t reflect the algorithm behind them.

:root {
  --scale: 1.26;
  --base: 1rem;

  --h6: var(--base); /* 16px */
  --h5: calc(var(--h6) * var(--scale)); /* 20px */
  --h4: calc(var(--h5) * var(--scale)); /* 25px */
  --h3: calc(var(--h4) * var(--scale)); /* 32px */
  --h2: calc(var(--h3) * var(--scale)); /* 40px */
  --h1: calc(var(--h2) * var(--scale)); /* 51px */
}

It’s easy to re-create that in CSS. I have a custom property for the scale and one for the base font size. My H6 equals the base size. The H5 is the result of the size of the H6 times scale. The H4 takes the size of the H5 multiplied by the scale, etc. That’s fine, but I don’t like that for every font size you have to reference the previous font size, and I also don’t like the repetition.

:root {
  --scale: 1.26;
  --base: 1rem;

  --h6: var(--base);
  --h5: calc(var(--base) * var(--scale)); 
  --h4: calc(var(--base) * var(--scale) * var(--scale)); 
  --h3: calc(var(--base) * var(--scale) * var(--scale) * var(--scale)); 
  --h2: calc(var(--base) * var(--scale) * var(--scale) * var(--scale) * var(--scale)); 
  --h1: calc(var(--base) * var(--scale) * var(--scale) * var(--scale) * var(--scale) * var(--scale)); 
}

Another way of writing that is to take the base font size multiplied by the scale for the H5, for the H4 you multiply the base font size by the scale and again by the scale, and so on.

When I saw that, I was sure that some dead dude probably already came up with a formula for that.

:root {
  --scale: 1.26;
  --base: 1rem;
  
  --h6: calc(var(--base) * pow(var(--scale), 0));
  --h5: calc(var(--base) * pow(var(--scale), 1));
  --h4: calc(var(--base) * pow(var(--scale), 2));
  --h3: calc(var(--base) * pow(var(--scale), 3));
  --h2: calc(var(--base) * pow(var(--scale), 4));
  --h1: calc(var(--base) * pow(var(--scale), 5));
}

h1 { font-size: var(--h1); }
h2 { font-size: var(--h2); }
h3 { font-size: var(--h3); }
h4 { font-size: var(--h4); }
h5 { font-size: var(--h5); }
h6 { font-size: var(--h6); }

Instead of multiplying the scale multiple times I now use the pow() function. The first value is the base number and the second value is the exponent. The larger exponent the larger the font size.

That’s much better now, but I still have a lot of repetition here.

:root {
  --scale: 1.26;
  --base: 1rem;
}

h1, h2, h3, h4, h5, h6 {
  font-size: calc(var(--base) * pow(var(--scale), var(--exponent, 0)));
}

h1 { --exponent: 5; }
h2 { --exponent: 4; }
h3 { --exponent: 3; }
h4 { --exponent: 2; }
h5 { --exponent: 1; }

To avoid repetition, I’m selecting all the headings and I’m setting to the font size to the base font size times the pow() function. The exponent defaults to 0 but you can override it using the —exponent custom property. I know that looks really strange because we are used to using the font-size property but this allows me to stay within my type scale. It enforces the sizing system in my CSS, very similar to what we did earlier with cascade layers.

I was really happy with that, but then I realised that it only applies to headings, but I may want to use the system for different elements, too.

:root {
  --scale: 1.26;
  --base: 1rem;
}

*, ::after, ::before {
  font-size: calc(var(--base) * pow(var(--scale), var(--exponent, 0)));
}

h1     { --exponent: 5; }
h2     { --exponent: 5; }
h3     { --exponent: 3; }
h4     { --exponent: 2; }
h5     { --exponent: 1; }
.big   { --exponent: 10; }
.small { --exponent: -1; }

Don’t try this at home, or actually try at home but don’t try to work. Instead of selecting headings only, I’m selecting all the elements on the page and I’m using my formula here. It works fine for me, but it’s dangerous because it resets all font sizes and it messes with inheritance. If I want a really large font size on a random element, I can just use a large exponent or if you want a small font size I use a negative value.

It’s cool that I’m now forced to use my type scale, but what if I don’t want to?

:root {
  --scale: 1.26;
  --base: 1rem;
}

*, ::after, ::before {
  --_type-power: pow(var(--scale), var(--exponent, 0));
  --_type-scale-formula: calc(var(--base) * var(--_type-power));
  font-size: var(--font-size, var(--_type-scale-formula));
}

.big { --exponent: 10; }
.small { —exponent: -1; }
.custom { --font-size: 2rem; }

I’m still using my formula, but now it’s the fallback for a custom property. If the —font-size custom properties is defined, that’s the font size. If not, it defaults to the formula.

:root {
  --color-1: #007e6f;
  --color-2: #e8c52c;
  --color-3: #084786;
  --color-4: #e7436d;
  --color-5: #fcfcfc;
}

Another interesting topic is colour. For the most of my part of my career, I didn’t care much about colour and also didn’t know anything about colour theory, but Marc invited me to speak at Beyond Tellerrand in Berlin…

:root {
  --color-1: oklch(0.52 0.12 182.55);
  --color-2: oklch(0.83 0.16 95);
  --color-3: oklch(0.4 0.12 253.73);
  --color-4: oklch(0.63 0.2 9.96);
  --color-5: oklch(0.99 0 0);
}

You can see how I have five custom properties with five different colours but usually when we work with colour we need much more colours with different lighter and darker variations of our base colours.

:root {
  --color-1: oklch(0.52 0.12 182.55);
  --color-1-100: oklch(from var(--color-1) 0.9 c h);
  --color-1-200: oklch(from var(--color-1) 0.8 c h);
  --color-1-300: oklch(from var(--color-1) 0.7 c h);
  --color-1-400: oklch(from var(--color-1) 0.6 c h);
  --color-1-500: oklch(from var(--color-1) 0.5 c h);
  --color-1-600: oklch(from var(--color-1) 0.4 c h);
  --color-1-700: oklch(from var(--color-1) 0.3 c h);
  --color-1-800: oklch(from var(--color-1) 0.2 c h);
  --color-1-900: oklch(from var(--color-1) 0.1 c h);
}

With relative colour syntax in CSS that’s easy to do. We use a colour function, extract the channels we need from our base colour, in this case the chroma and the hue, and then we change the lightness.

Customisation

:root { 
  --magic: true; 
}

That’s why I select the root element and I set —magic to true.

@container style(--magic: true) {
  header, main, footer {
    --_inline-size: ((var(--oli-s-page-width) - var(--oli-s-page-max-width)) / 2);
    --_wrapper-layout: max(0px, var(--_inline-size));
  }

  main {
    --_main-margin: 0 var(--_wrapper-layout);
  }

  header {
    --_header-align-items: center;
    --_header-justify-content: space-between;
    --_header-margin: 0 var(--_wrapper-layout) var(--oli-s-header-margin-block-end);
  }
}

That’s possible thanks to container style queries. In this query I check if —magic is set to true. If that’s the case, I change the layout and styling of the header, navigation and other elements.

:root {
  --oli-s-magic: true; 
  --oli-s-layout: horizontal;
  --oli-s-font-stack: transitional;
}

Right now, I have three settings: magic, one for layout that allows me to switch to a horizontal layout and one that allows me to switch the font stack.

:root {
  --_oli-font-stack-humanist: Seravek, "Gill Sans Nova", Ubuntu, Calibri,"DejaVu Sans", source-sans-pro, sans-serif;
  --_oli-font-stack-geometric: Avenir, Montserrat, Corbel, "URW Gothic", source-sans-pro, sans-serif;
  --_oli-font-family-old: "Iowan Old Style", "Palatino Linotype", "URW Palladio L", P052, serif;
  --_oli-font-family-slab-serif: Rockwell, "Rockwell Nova", "Roboto Slab", "DejaVu Serif", "Sitka Small", serif;
  --_oli-font-family-transitional: Charter, 'Bitstream Charter', 'Sitka Text', Cambria, serif;
  --_oli-font-family-monospace-slab-serif: 'Nimbus Mono PS', 'Courier New', monospace;
}

body {
  @container style(--oli-s-font-stack: geometric) {
    --oli-s-font-family: var(--_oli-font-stack-geometric);
  }

  @container style(--oli-s-font-stack: old) {
      --oli-s-font-family: var(--_oli-font-family-old);
  }

  @container style(--oli-s-font-stack: humanist) {
      --oli-s-font-family: var(--_oli-font-stack-humanist);
  }

  @container style(--oli-s-font-stack: slab-serif) {
      --oli-s-font-family: var(--_oli-font-family-slab-serif);
  }

  @container style(--oli-s-font-stack: transitional) {
      --oli-s-font-family: var(--_oli-font-family-transitional);
  }

  @container style(--oli-s-font-stack: monospace-slab-serif) {
      --oli-s-font-family: var(--_oli-font-family-monospace-slab-serif);
  }
}

I’m using some of the font stacks from modernfontstacks.com. That’s basically a switch statement in CSS.

:root {
  --oli-s-magic: true; 
  --oli-s-layout: vertical;
  --oli-s-font-stack: humanist;
}

The same site with two different settings. It still feels like the original but it has it’s own character.

:root {
  --oli-s-magic: true; 
  --oli-s-layout: horizontal;
  --oli-s-font-stack: transitional;
  --oli-s-scroll-behavior: smooth; 
  --oli-s-page-max-width: 80rem; 
  --oli-s-page-width: 100%; 
  --oli-s-page-start-column-width: 16rem; 
  --oli-s-page-text-scale: 1.4; 
  --oli-s-page-line-height: 1.7; 
  --oli-s-page-padding: 2rem;
  --oli-s-page-background-color: var(--oli-g-colors-color-5); 
  --oli-s-page-color: var(--oli-g-colors-black);
  --oli-s…
}

On top of my three custom properties with made-up values I also have a bunch of properties that I use directly without querying them. That gives me a high level of customisation.

@font-face { font-family: "Pangea"; src: url("../fonts/Pangea-MediumWeb.woff2") format("woff2"); font-weight: 500;}

@layer core.tokens {
  :root {
    --oli-s-layout: vertical;
    --oli-g-colors-color-1: oklch(0.32 0 0);
    --oli-g-colors-color-2: oklch(0.8 0.17 98.31);
    --oli-g-colors-color-4: oklch(0.66 0.21 39.19);
    --oli-g-colors-color-5: oklch(0.99 0 0);
    --oli-s-link-color: var(--oli-g-colors-color-4-500);
    --oli-s-link-color-visited: var(--oli-g-colors-color-4-600);
    --oli-s-figure-background-color: var(--oli-g-colors-color-2-100);
    --oli-s-table-th-background-color: var(--oli-g-colors-color-2-100);

    --oli-s-heading-1-color: var(--oli-g-colors-color-1);
    --oli-s-heading-1-font-weight: 600;
    --oli-s-heading-1-scalefactor: 8;
    --oli-s-heading-2-color: var(--oli-g-colors-color-4-400);
    --oli-s-heading-2-font-weight: 600;
    --oli-s-heading-3-font-weight: 500;
    --oli-s-page-padding: 4rem;
    --oli-s-page-start-column-width: 20rem;
    --oli-s-font-family: "Pangea";
  }
}

@layer core.base {
  h3 a {
    --oli-s-link-color: var(--oli-g-colors-color-1);
    --oli-s-link-color-visited: var(--oli-g-colors-color-1);
  }
}

Than I changed some of the settings, like the layout, color, paddings, and font weights.

Componentisation

<div class="card">
  <div class="card-inner">
    <div class="card-content">
      <h3 class="card-heading">Demo</h3>
      <p>Content</p>
    </div>

    <img src="image.jpg" alt="" class="card-media">
  </div>
</div>

Let’s say we have a good old card component. Heading, some content, and an image.

<div class="card" style="--card-size: l">
  <div class="card-inner">
    …
  </div>
</div>

If we want a larger variation of the same component, we set —card-size: l;

<div class="card" style="--card-size: l; --card-axis: x">
  <div class="card-inner">
    …
  </div>
</div>

We can also change the layout by defining another property, —card-axis: x;

.card-custom {
  --card-size: l; 
  --card-axis: x; 
  --card-scheme: dark
}

The big difference is that we’re not redeclaring random properties, we’re configuring our predefined settings for the component. There are also other advantages.

<div class="news" style="--card-size: s">
  <div class="card">…</div>
  <div class="card">…</div>
  <div class="card">…</div>
  <div class="card">…</div>
</div>

Of course, working with classes is still fine, that’s not the point, but one of the advantages of using custom properties is inheritance. If you want all items in a parent item so adapt a certain size, for example, you can define the size on the parent and the children will react to it.

.card {
  --_card-max-inline-size: 13rem;
  max-inline-size: var(--_card-max-inline-size);
}

@media (min-width: 48rem) {
  .card {
    --_card-max-inline-size: 23rem;
  }
}

.card--large {
  --_card-max-inline-size: 23rem;
}

Another advantage is that you can write DRYer code. Let’s say you define a max-width for the card. On larger screen you increase the max-width. You do the same in a custom class. You have to define the value once for the media query and than repeat it for the custom class.

.card-inner {
  --_card-max-inline-size: 13rem;
  max-inline-size: var(--_card-max-inline-size);
}

@container style(--card-size: l) {
  .card-inner {
    --_card-max-inline-size: 23rem;
  }
}

@media (min-width: 48rem) {
  .card {
     --card-size: l;
  }
}

.card--large {
  --card-size: l;
}

With container style queries you define the value once and than you just repeat the setting. That’s very similar to using mixins.

The only downside is that it doesn’t work in Firefox at the moment, but maybe there’s someone in the audience today who recently started working at Firefox, who can push this topic for us. Pu-pu-push it, Pu-pu-push it real good