Bruke CSS Cascade Layers for å administrere tilpassede stiler i et medvindsprosjekt

Hvis en verktøyklasse bare gjør én ting, er sjansen stor for at du ikke vil at den skal overstyres av stiler som kommer fra andre steder. En tilnærming er å bruke !important for å være 100 % sikker på at stilen vil bli brukt, uavhengig av spesifisitetskonflikter.

Tailwind-konfigurasjonsfilen har en !important alternativ som automatisk legges til !important til hver bruksklasse. Det er ikke noe galt med å bruke !important på denne måten, men i dag er det bedre måter å håndtere spesifisitet på. Ved hjelp av CSS-kaskadelag vi kan unngå den tunge tilnærmingen med å bruke !important.

Kaskadelag lar oss gruppere stiler i "lag". Et lags forrang slår alltid spesifisiteten til en velger. Spesifisitet er bare viktig inne i hvert lag. Etablering av en fornuftig lagrekkefølge bidrar til å unngå stylingkonflikter og spesifisitetskriger. Det er det som gjør CSS Cascade Layers til et flott verktøy for administrere tilpassede stiler sammen med stiler fra tredjeparts rammeverk, som Tailwind.

En medvindskilde .css fil starter vanligvis noe slikt:

@tailwind base;
@tailwind components;
@tailwind utilities;
@tailwind variants;

La oss ta en titt på offisielle Tailwind-dokumenter om direktiver:

Direktiver er tilpassede Tailwind-spesifikke at-regler du kan bruke i din CSS som tilbyr spesiell funksjonalitet for Tailwind CSS-prosjekter. Bruke @tailwind direktiv om å sette inn Tailwind's base, components, utilities og variants stiler inn i CSS-en din.

I utdata-CSS-filen som bygges, tilbakestilles Tailwinds CSS - kjent som Forflyging — er inkludert først som en del av basisstilene. Resten av base består av CSS-variabler som trengs for at Tailwind skal fungere. components er et sted for deg å legge til dine egne tilpassede klasser. Eventuelle verktøyklasser du har brukt i markeringen din, vises neste gang. Varianter er stiler for ting som sveve- og fokustilstander og responsive stiler, som vises sist i den genererte CSS-filen.

Medvinden @layer Direktiver

Forvirrende nok har Tailwind sin egen @layer syntaks. Denne artikkelen handler om CSS-standarden, men la oss ta en rask titt på Tailwind-versjonen (som blir kompilert og ikke havner i utdata-CSS). Medvinden @layer direktivet er en måte å injisere dine egne ekstra stiler i en spesifisert del av utdata-CSS-filen.

For eksempel å legge til dine egne stiler til base stiler, vil du gjøre følgende:

@layer base {
  h1 {
    font-size: 30px;
  }
}

De components laget er tomt som standard - det er bare et sted å sette dine egne klasser. Hvis du gjorde ting på Tailwind-måten, ville du sannsynligvis brukt @apply (selv om skaperen av Tailwind nylig frarådet det), men du kan også skrive klasser på vanlig måte:

@layer components {
  .btn-blue {
    background-color: blue;
    color: white;
  }
}

CSS-standarden er mye kraftigere. La oss komme tilbake til det...

Bruker CSS-standarden @layer

Her er hvordan vi kan omskrive dette for å bruke CSS-standarden @layer:

@layer tailwind-base, my-custom-styles, tailwind-utilities;

@layer tailwind-base {
  @tailwind base;
}

@layer tailwind-utilities {
  @tailwind utilities;
  @tailwind variants;
} 

I motsetning til Tailwind-direktivet, blir disse ikke kompilert bort. De blir forstått av nettleseren. Faktisk vil DevTools i Edge, Chrome, Safari og Firefox til og med vise deg alle lag du har definert.

Du kan ha så mange lag du vil – og navngi dem hva du vil – men i dette eksemplet er alle mine egendefinerte stiler i ett enkelt lag (my-custom-styles). Den første linjen etablerer lagrekkefølgen:

@layer tailwind-base, my-custom-styles, tailwind-utilities;

Dette må gis på forhånd. Sørg for å inkludere denne linjen før enhver annen kode som bruker @layer. Det første laget i listen vil være minst kraftig, og det siste laget i listen vil være mest kraftig. Det betyr tailwind-base er den minst kraftig lag og eventuell kode i det vil bli overstyrt av alle de påfølgende lagene. Det betyr også tailwind-utilities vil alltid trumfe alle andre stiler - uavhengig av kilderekkefølge eller spesifisitet. (Verktøy og varianter kunne gå i separate lag, men vedlikeholderne av Tailwind vil sikre at varianter alltid trumfer verktøy, så lenge du inkluderer variantene under verktøydirektivet.)

Alt som ikke er i et lag vil overstyre alt som er i et lag (med det ene unntaket er stiler som bruker !important). Så du kan også velge å forlate utilities og variants utenfor ethvert lag:

@layer tailwind-base, tailwind-components, my-custom-styles;

@layer tailwind-base {
  @tailwind base;
}

@layer tailwind-components {
  @tailwind components;
}

@tailwind utilities;
@tailwind variants;

Hva kjøpte dette egentlig for oss? Det er mange ganger når avanserte CSS-velgere kommer godt med. La oss lage en versjon av :focus-within som bare reagerer på tastaturfokus i stedet for museklikk ved å bruke :has velger (som lander i Chrome 105). Dette vil style et overordnet element når noen av dets barn får fokus. Tailwind 3.1 introdusert tilpassede varianter - f.eks <div class="[&:has(:focus-visible)]:outline-red-600"> – men noen ganger er det lettere å bare skrive CSS:

@layer tailwind-base, my-custom-styles;
@layer tailwind-base {
  @tailwind base;
}

@tailwind utilities;

@layer my-custom-styles {
  .radio-container {
    padding: 4px 24px;
    border: solid 2px rgb(230, 230, 230);
  }
  .radio-container:has(:focus-visible) {
    outline: solid 2px blue;
  }
}

La oss si at vi bare i ett tilfelle ønsker å overstyre outline-color fra blue til noe annet. La oss si at elementet vi jobber med har både Tailwind-klassen .outline-red-600 og vår egen .radio-container:has(:focus-visible) klasse:

<div class="outline-red-600 radio-container"> ... </div>

Hvilken outline-color vil vinne?

Vanligvis, jo høyere spesifisitet av .radio-container:has(:focus-visible) vil bety at Tailwind-klassen ikke har noen effekt - selv om den er lavere i kilderekkefølgen. Men i motsetning til medvinden @layer direktiv som er avhengig av kilderekkefølge, CSS-standarden @layer overstyrer spesifisitet.

Som et resultat kan vi bruke komplekse velgere i våre egne tilpassede stiler, men likevel overstyre dem med Tailwinds verktøyklasser når vi trenger det – uten å måtte ty til tunghendt !important bruk for å få det vi ønsker.