CSS @apply-reglen: Fremkomsten og faldet af native mixins og moderne alternativer

I webudviklingens evigt udviklende landskab er jagten på renere, mere vedligeholdelsesvenlig og genbrugelig kode konstant. I årevis har udviklere lænet sig op ad CSS preprocessors som Sass og Less for at tilføje programmatisk kraft til stylesheets. En af de mest elskede funktioner fra disse værktøjer er mixin – en måde at definere en genbrugelig blok af CSS-deklarationer på. Dette førte til et naturligt spørgsmål: kunne vi have denne kraftfulde funktion native i CSS? For en tid så svaret ud til at være ja, og navnet var @apply.

@apply-reglen var et lovende forslag, der havde til formål at bringe mixin-lignende funktionalitet direkte ind i browseren ved at udnytte kraften i CSS Custom Properties. Den lovede en fremtid, hvor vi kunne definere genbrugelige stil-snippets i ren CSS og anvende dem overalt, endda opdatere dem dynamisk med JavaScript. Men hvis du er udvikler i dag, vil du ikke finde @apply i nogen stabil browser. Forslaget blev i sidste ende trukket tilbage fra den officielle CSS-specifikation.

Denne artikel er en omfattende udforskning af CSS @apply-reglen. Vi vil rejse gennem, hvad den var, det kraftfulde potentiale den havde for stilkomposition, de komplekse årsager til dens forældelse, og vigtigst af alt, de moderne, produktionsklare alternativer, der løser de samme problemer i nutidens udviklingsøkosystem.

Hvad var CSS @apply-reglen?

I sin kerne var @apply-reglen designet til at tage et sæt CSS-deklarationer gemt i en custom property og "anvende" dem inden i en CSS-regel. Dette tillod udviklere at skabe, hvad der i det væsentlige var "property bags" eller "regelsæt", der kunne genbruges på tværs af flere selektorer, og dermed efterleve Don't Repeat Yourself (DRY) princippet.

Konceptet var bygget på CSS Custom Properties (ofte kaldet CSS-variabler). Mens vi typisk bruger custom properties til at gemme enkeltværdier som en farve (--brand-color: #3498db;) eller en størrelse (--font-size-md: 16px;), udvidede forslaget til @apply deres kapacitet til at indeholde hele blokke af deklarationer.

Den foreslåede syntaks

Syntaksen var ligetil og intuitiv for alle, der er bekendt med CSS. Først skulle man definere en custom property, der indeholdt en blok af CSS-deklarationer, omsluttet af krøllede parenteser {}.

            
:root {
  --primary-button-styles: {
    background-color: #007bff;
    color: #ffffff;
    border: 1px solid transparent;
    padding: 0.5rem 1rem;
    font-size: 1rem;
    border-radius: 0.25rem;
    cursor: pointer;
    transition: background-color 0.2s ease-in-out;
  };
}

            

              
                Copy
              
            
          

Derefter kunne man, inden i enhver CSS-regel, bruge @apply at-reglen til at indsætte hele den blok af stilarter:

            
.btn-primary {
  @apply --primary-button-styles;
}

.form-submit-button {
  @apply --primary-button-styles;
  margin-top: 1rem; /* Du kunne stadig tilføje andre styles */
}

            

              
                Copy
              
            
          

I dette eksempel ville både .btn-primary og .form-submit-button arve det komplette sæt af stilarter defineret i --primary-button-styles. Dette var en markant afvigelse fra den standard var()-funktion, som kun kan erstatte en enkelt værdi i en enkelt property.

Vigtigste tilsigtede fordele

• Genbrugelighed af kode: Den mest åbenlyse fordel var eliminering af gentagelse. Almindelige mønstre som knap-stilarter, kort-layouts eller advarselsbokse kunne defineres én gang og anvendes overalt.
• Forbedret vedligeholdelse: For at opdatere udseendet af alle primære knapper skulle du kun redigere --primary-button-styles custom property. Ændringen ville derefter blive udbredt til alle elementer, hvor den blev anvendt.
• Dynamisk tematisering: Fordi det var baseret på custom properties, kunne disse mixins ændres dynamisk med JavaScript, hvilket muliggjorde kraftfulde runtime-tematiseringsmuligheder, som preprocessors (der opererer på kompileringstidspunktet) ikke kan tilbyde.
• Brobygning: Det lovede at bringe en meget elsket funktion fra preprocessor-verdenen ind i native CSS, hvilket reducerede afhængigheden af build-værktøjer for netop denne funktionalitet.

Løftet om @apply: Native mixins og stilkomposition

Potentialet i @apply gik langt ud over simpel genbrug af stilarter. Det åbnede op for to kraftfulde koncepter for CSS-arkitektur: native mixins og deklarativ stilkomposition.

Et native svar på preprocessor-mixins

I årevis har Sass været guldstandarden for mixins. Lad os sammenligne, hvordan Sass opnår dette, med hvordan @apply var tænkt at fungere.

En typisk Sass Mixin:

            
@mixin flexible-center {
  display: flex;
  justify-content: center;
  align-items: center;
}

.hero-banner {
  @include flexible-center;
  height: 100vh;
}

.modal-content {
  @include flexible-center;
  flex-direction: column;
}

            

              
                Copy
              
            
          

Det tilsvarende med @apply:

            
:root {
  --flexible-center: {
    display: flex;
    justify-content: center;
    align-items: center;
  };
}

.hero-banner {
  @apply --flexible-center;
  height: 100vh;
}

.modal-content {
  @apply --flexible-center;
  flex-direction: column;
}

            

              
                Copy
              
            
          

Syntaksen og udvikleroplevelsen var bemærkelsesværdigt ens. Den afgørende forskel lå dog i udførelsen. Sass @mixin behandles under et build-step og outputter statisk CSS. @apply-reglen ville være blevet behandlet af browseren ved runtime. Denne skelnen var både dens største styrke og, som vi vil se, dens endelige fald.

Deklarativ stilkomposition

@apply ville have gjort det muligt for udviklere at bygge komplekse komponenter ved at sammensætte mindre, enkeltformåls stil-snippets. Forestil dig at bygge et UI-komponentbibliotek, hvor du har grundlæggende blokke for typografi, layout og udseende.

            
:root {
  --typography-body: {
    font-family: 'Inter', sans-serif;
    font-size: 16px;
    line-height: 1.5;
    color: #333;
  };

  --card-layout: {
    padding: 1.5rem;
    border-radius: 8px;
    box-shadow: 0 4px 8px rgba(0,0,0,0.1);
  };

  --theme-light: {
    background-color: #ffffff;
    border: 1px solid #ddd;
  };

  --theme-dark: {
    background-color: #2c3e50;
    border: 1px solid #444;
    color: #ecf0f1;
  };
}

.article-card {
  @apply --typography-body;
  @apply --card-layout;
  @apply --theme-light;
}

.user-profile-card.dark-mode {
  @apply --typography-body;
  @apply --card-layout;
  @apply --theme-dark;
}

            

              
                Copy
              
            
          

Denne tilgang er meget deklarativ. CSS'en for .article-card angiver tydeligt sin sammensætning: den har brødtekst-typografi, et kort-layout og et lyst tema. Dette gør koden lettere at læse og ræsonnere om.

Den dynamiske superkraft

Den mest overbevisende funktion var dens runtime-dynamik. Da --card-theme kunne være en almindelig custom property, kunne man udskifte hele regelsæt med JavaScript.

            
/* CSS */
.user-profile-card {
  @apply --typography-body;
  @apply --card-layout;
  @apply var(--card-theme, --theme-light); /* Anvend et tema, med light som standard */
}

/* JavaScript */
const themeToggleButton = document.getElementById('theme-toggle');
themeToggleButton.addEventListener('click', () => {
  const root = document.documentElement;
  const isDarkMode = root.style.getPropertyValue('--card-theme') === '--theme-dark';

  if (isDarkMode) {
    root.style.setProperty('--card-theme', '--theme-light');
  } else {
    root.style.setProperty('--card-theme', '--theme-dark');
  }
});

            

              
                Copy
              
            
          

Dette hypotetiske eksempel viser, hvordan man kunne skifte en komponent mellem et lyst og et mørkt tema ved at ændre en enkelt custom property. Browseren skulle så gen-evaluere @apply-reglen og udskifte en stor del af stilarterne i farten. Dette var en utrolig kraftfuld idé, men det antydede også den enorme kompleksitet, der boblede under overfladen.

Den store debat: Hvorfor blev @apply fjernet fra CSS-specifikationen?

Med en så overbevisende vision, hvorfor forsvandt @apply? Beslutningen om at fjerne den blev ikke truffet let. Det var resultatet af lange og komplekse diskussioner inden for CSS Working Group (CSSWG) og blandt browser-leverandører. Årsagerne kogte ned til betydelige problemer med ydeevne, kompleksitet og de grundlæggende principper i CSS.

1. Uacceptable konsekvenser for ydeevnen

Dette var den primære årsag til dens fald. CSS er designet til at være utroligt hurtigt og effektivt. Browserens renderingsmotor kan parse stylesheets, bygge CSSOM (CSS Object Model) og anvende stilarter på DOM'en i en højt optimeret sekvens. @apply-reglen truede med at smadre disse optimeringer.

• Parsing og validering: Når en browser støder på en custom property som --main-color: blue;, behøver den ikke at validere værdien `blue`, før den rent faktisk bruges i en property som `color: var(--main-color);`. Med @apply ville browseren imidlertid skulle parse og validere en hel blok af vilkårlige CSS-deklarationer inde i en custom property. Dette er en meget tungere opgave.
• Kaskadekompleksitet: Den største udfordring var at finde ud af, hvordan @apply ville interagere med kaskaden. Når man anvender @apply på en blok af stilarter, hvor passer de stilarter så ind i kaskaden? Har de samme specificitet som den regel, de er i? Hvad sker der, hvis en @apply'd property senere overskrives af en anden stil? Dette skabte et "late-breaking" kaskadeproblem, der var beregningsmæssigt dyrt og svært at definere konsekvent.
• Uendelige løkker og cirkulære afhængigheder: Det introducerede muligheden for cirkulære referencer. Hvad hvis --mixin-a anvendte --mixin-b, som igen anvendte --mixin-a? At opdage og håndtere disse tilfælde ved runtime ville tilføje betydelig overhead til CSS-motoren.

I bund og grund krævede @apply, at browseren skulle udføre en betydelig mængde arbejde, der normalt håndteres af build-værktøjer på kompileringstidspunktet. At udføre dette arbejde effektivt ved runtime for hver stil-genberegning blev anset for at være for dyrt fra et ydeevneperspektiv.

2. Brud på kaskadens garantier

CSS-kaskaden er et forudsigeligt, omend undertiden komplekst, system. Udviklere stoler på dens regler om specificitet, arv og kildeorden for at ræsonnere om deres stilarter. @apply-reglen introducerede et niveau af indirektion, der gjorde denne ræsonnement meget sværere.

Overvej dette scenarie:

            
:root {
  --my-mixin: {
    color: blue;
  };
}

div {
  @apply --my-mixin; /* farven er blå */
  color: red;        /* farven er nu rød */
}

            

              
                Copy
              
            
          

Dette virker simpelt nok. Men hvad nu hvis rækkefølgen var omvendt?

            
div {
  color: red;
  @apply --my-mixin; /* Overskriver dette den røde farve? */
}

            

              
                Copy
              
            
          

CSSWG skulle beslutte: opfører @apply sig som en shorthand-property, der udvides på stedet, eller opfører den sig som et sæt deklarationer, der indsættes med deres egen kildeorden? Denne tvetydighed underminerede den centrale forudsigelighed i CSS. Det blev ofte beskrevet som "magi" – et udtryk, udviklere bruger om adfærd, der ikke er let at forstå eller fejlfinde. At introducere denne form for magi i kernen af CSS var en betydelig filosofisk bekymring.

3. Udfordringer med syntaks og parsing

Selve syntaksen, selvom den virkede simpel, skabte problemer. At tillade vilkårlig CSS inde i en custom property-værdi betød, at CSS-parseren skulle være meget mere kompleks. Den skulle kunne håndtere indlejrede blokke, kommentarer og potentielle fejl inden i selve property-definitionen, hvilket var en markant afvigelse fra, hvordan custom properties var designet til at fungere (at indeholde, hvad der i bund og grund er en streng, indtil substitution).

I sidste ende var konsensus, at omkostningerne ved ydeevne og kompleksitet langt oversteg fordelene for udvikler-bekvemmelighed, især da andre løsninger allerede eksisterede eller var på vej.

Arven efter @apply: Moderne alternativer og bedste praksis

Drømmen om genbrugelige stil-snippets i CSS er langt fra død. De problemer, som @apply sigtede mod at løse, er stadig meget reelle, og udviklingsfællesskabet har siden da omfavnet flere kraftfulde, produktionsklare alternativer. Her er, hvad du bør bruge i dag.

Alternativ 1: Behersk CSS Custom Properties (den tilsigtede metode)

Den mest direkte, native løsning er at bruge CSS Custom Properties til deres oprindelige formål: at gemme enkelte, genbrugelige værdier. I stedet for at oprette et mixin for en knap, opretter du et sæt custom properties, der definerer knappens tema. Denne tilgang er kraftfuld, performant og fuldt understøttet af alle moderne browsere.

Eksempel: Opbygning af en komponent med Custom Properties

            
:root {
  --btn-padding-y: 0.5rem;
  --btn-padding-x: 1rem;
  --btn-font-size: 1rem;
  --btn-border-radius: 0.25rem;
  --btn-transition: color .15s ease-in-out, background-color .15s ease-in-out;
}

.btn {
  /* Strukturelle stilarter */
  display: inline-block;
  padding: var(--btn-padding-y) var(--btn-padding-x);
  font-size: var(--btn-font-size);
  border-radius: var(--btn-border-radius);
  transition: var(--btn-transition);
  cursor: pointer;
  text-align: center;
  border: 1px solid transparent;
}

.btn-primary {
  /* Tematisering via custom properties */
  --btn-bg: #007bff;
  --btn-color: #ffffff;
  --btn-hover-bg: #0056b3;

  background-color: var(--btn-bg);
  color: var(--btn-color);
}

.btn-primary:hover {
  background-color: var(--btn-hover-bg);
}

.btn-secondary {
  --btn-bg: #6c757d;
  --btn-color: #ffffff;
  --btn-hover-bg: #5a6268;

  background-color: var(--btn-bg);
  color: var(--btn-color);
}

.btn-secondary:hover {
  background-color: var(--btn-hover-bg);
}

            

              
                Copy
              
            
          

Denne tilgang giver dig tematiserede, vedligeholdelsesvenlige komponenter ved hjælp af native CSS. Strukturen er defineret i .btn, og temaet (den del, du måske ville have lagt i en @apply-regel) styres af custom properties, der er scopet til modifikatorer som .btn-primary.

Alternativ 2: Utility-First CSS (f.eks. Tailwind CSS)

Utility-first frameworks som Tailwind CSS har taget konceptet om stilkomposition til sin logiske konklusion. I stedet for at skabe komponentklasser i CSS, sammensætter du stilarter direkte i din HTML ved hjælp af små, enkeltformåls utility-klasser.

Interessant nok har Tailwind CSS sit eget @apply-direktiv. Det er afgørende at forstå, at dette IKKE er det native CSS @apply. Tailwinds @apply er en build-time-funktion, der virker inden for dets økosystem. Den læser dine utility-klasser og kompilerer dem til statisk CSS, hvilket undgår alle runtime-ydeevneproblemerne fra det native forslag.

Eksempel: Brug af Tailwinds @apply

            
/* I din CSS-fil, der behandles af Tailwind */
.btn-primary {
  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded hover:bg-blue-700;
}

/* I din HTML */
<button class="btn-primary">
  Primær knap
</button>

            

              
                Copy
              
            
          

Her tager Tailwinds @apply en liste af utility-klasser og opretter en ny komponentklasse, .btn-primary. Dette giver den samme udvikleroplevelse med at skabe genbrugelige sæt af stilarter, men gør det sikkert på kompileringstidspunktet.

Alternativ 3: CSS-in-JS-biblioteker

For udviklere, der arbejder inden for JavaScript-frameworks som React, Vue eller Svelte, tilbyder CSS-in-JS-biblioteker (f.eks. Styled Components, Emotion) en anden kraftfuld måde at opnå stilkomposition på. De bruger JavaScripts egen kompositionsmodel til at bygge stilarter.

Eksempel: Mixins i Styled Components (React)

            
import styled, { css } from 'styled-components';

// Definer et mixin ved hjælp af en template literal
const buttonBaseStyles = css`
  background-color: #007bff;
  color: #ffffff;
  border: 1px solid transparent;
  padding: 0.5rem 1rem;
  border-radius: 0.25rem;
  cursor: pointer;
`;

// Opret en komponent og anvend mixin'et
const PrimaryButton = styled.button`
  ${buttonBaseStyles}

  &:hover {
    background-color: #0056b3;
  }
`;

// En anden komponent, der genbruger de samme grundlæggende stilarter
const SubmitButton = styled.input.attrs({ type: 'submit' })`
  ${buttonBaseStyles}
  margin-top: 1rem;
`;

            

              
                Copy
              
            
          

Dette udnytter den fulde kraft af JavaScript til at skabe genbrugelige, dynamiske og scopede stilarter, hvilket løser DRY-problemet inden for det komponentbaserede paradigme.

Alternativ 4: CSS Preprocessors (Sass, Less)

Lad os ikke glemme de værktøjer, der startede det hele. Sass og Less er stadig utroligt kraftfulde og meget udbredte. Deres mixin-funktionalitet er moden, funktionsrig (de kan acceptere argumenter) og fuldstændig pålidelig, fordi de, ligesom Tailwinds @apply, opererer på kompileringstidspunktet.

For mange projekter, især dem der ikke er bygget på et tungt JavaScript-framework, er en preprocessor stadig den enkleste og mest effektive måde at håndtere komplekse, genbrugelige stilarter på.

Konklusion: Lærdomme fra @apply-eksperimentet

Historien om CSS @apply-reglen er en fascinerende casestudie i udviklingen af webstandarder. Den repræsenterer et modigt forsøg på at bringe en elsket udviklerfunktion ind på den native platform. Dens endelige tilbagetrækning var ikke en fiasko for idéen, men et vidnesbyrd om CSS Working Groups engagement i ydeevne, forudsigelighed og den langsigtede sundhed for sproget.

De vigtigste takeaways for udviklere i dag er:

• Brug CSS Custom Properties til værdier, ikke regelsæt. Brug dem til at skabe kraftfulde temasystemer og opretholde designkonsistens.
• Vælg det rigtige værktøj til komposition. Problemet, som @apply forsøgte at løse – stilkomposition – håndteres bedst af dedikerede værktøjer, der opererer ved build-time (som Tailwind CSS eller Sass) eller inden for en komponents kontekst (som CSS-in-JS).
• Forstå 'hvorfor' bag webstandarder. At vide, hvorfor en funktion som @apply blev afvist, giver os en dybere påskønnelse af kompleksiteten i browser-engineering og de grundlæggende principper i CSS, som kaskaden.

Selvom vi måske aldrig vil se en native @apply-regel i CSS, lever dens ånd videre. Ønsket om en mere modulær, komponentdrevet og DRY-tilgang til styling har formet de moderne værktøjer og bedste praksis, vi bruger hver dag. Webplatformen fortsætter med at udvikle sig med funktioner som CSS Nesting, @scope og Cascade Layers, der giver nye, native måder at skrive mere organiseret og vedligeholdelsesvenlig CSS på. Rejsen mod en bedre stylingoplevelse er i gang, og de lærdomme, der er draget fra eksperimenter som @apply, er det, der baner vejen fremad.