Du kan snart bruge indlejrede erklæringer i dine CSS-typografiark, men du skal være opmærksom på detaljerne, hvis du migrerer fra Sass.
Siden den blev lanceret, har CSS hårdnakket nægtet at understøtte en syntaks til indlejringsvælgere. Alternativet har altid været at bruge en CSS-forprocessor som Sass. Men i dag er nesting officielt en del af native CSS. Du kan prøve denne funktion direkte i moderne browsere.
Hvis du migrerer fra Sass, skal du tage højde for eventuelle forskelle mellem indbygget indlejring og Sass-nesting. Der er nogle vigtige forskelle mellem begge indlejringsfunktioner, og det er afgørende at være opmærksom på dem, hvis du skifter.
Du skal bruge "&" med elementvælgere i indbygget CSS
CSS Nesting er stadig et udkast til specifikation med varierende browserunderstøttelse. Sørg for at tjekke websteder som caniuse.com for opdateret information.
Her er et eksempel på den type indlejring, du ville se i Sass, ved hjælp af SCSS-syntaksen:
.nav {
ul { display: flex; }
a { color: black; }
}
Denne CSS-blok specificerer, at enhver uordnet liste inde i et element med en nav klasse justeres som en flex kolonne, én måde at udlægning af HTML-elementer på siden. Derudover er al ankerlinktekst inde i elementer med en nav klasse skal være sort.
Nu, i native CSS, ville den slags indlejring være ugyldig. For at få det til at fungere, skal du inkludere og-tegnet (&) foran de indlejrede elementer, som sådan:
.nav {
& ul { display: flex; }
& a { color: black; }
}
Den tidlige version af CSS-indlejring tillod ikke indlejring af typevælgere. En nylig ændring betyder, at du ikke længere behøver at bruge "&", men ældre versioner af Chrome og Safari understøtter muligvis ikke denne opdaterede syntaks endnu.
Hvis du nu brugte en vælger, der starter med et symbol (f.eks. klassevælger) til målrette mod en bestemt del af siden, kan du udelade og-tegnet. Så følgende syntaks ville fungere i både native CSS og Sass:
.nav {
.nav-list { display: flex; }
.nav-link { color: black; }
}
Du kan ikke oprette en ny vælger ved hjælp af "&" i Native CSS
En af de funktioner, du sikkert elsker ved Sass, er evnen til at gøre noget som dette:
.nav {
&-list { display: flex; }
&-link { color: black; }
}
Denne Sass-kode kompilerer til følgende rå CSS:
.nav-list {
display: flex;
}
.nav-link {
color: black;
}
I indbygget CSS kan du ikke oprette en ny vælger ved at bruge "&". Sass-kompileren erstatter "&" med det overordnede element (f.eks. .nav), men indbygget CSS vil behandle "&" og delen efter det som to separate vælgere. Som et resultat vil den forsøge at lave en sammensat vælger, som ikke giver det samme resultat.
Dette eksempel vil dog fungere i indbygget CSS:
.nav {
&.nav-list { display: flex; }
&.nav-link { color: black; }
}
Dette virker, fordi den første vælger er den samme som nav.nav-liste i almindelig CSS, og den anden er den samme som nav.nav-link. Tilføjelse af et mellemrum mellem "&" og vælgeren ville svare til at skrive nav .nav-liste.
I native CSS, hvis du bruger og-tegnet som dette:
.nav {
&__nav-list { display: flex; }
&__nav-link { color: black; }
}
Det er det samme som at skrive dette:
__nav-list.nav {
display: flex;
}
__nav-link.nav {
color: black;
}
Dette kan komme som en overraskelse for dig, i betragtning af at både __nav-liste og __nav-link er inde i .nav vælger. Men et-tegnet placerer faktisk de indlejrede elementer foran det overordnede element.
Specificitet kan være forskellig
En anden ting at bemærke er indvirkningen på specificitet, der ikke sker i Sass, men sker i native CSS-nesting.
Så lad os sige, at du har en og en element. Med følgende CSS, en i et af disse elementer vil bruge en serif-skrifttype:
#main, article {
h2 {
font-family: serif;
}
}
Den kompilerede version af ovenstående Sass-kode er som følger:
#mainh2,
articleh2 {
font-family: serif;
}
Men den samme nesting-syntaks i native CSS vil producere et andet resultat, faktisk det samme som:
:is(#main, article) h2 {
font-family: serif;
}
Det er() selector håndterer specificitetsregler lidt anderledes end Sass-nesting. Grundlæggende er specificiteten af:er() bliver automatisk opgraderet til det mest specifikke element på listen over angivne argumenter.
Rækkefølgen af elementer kan ændre det valgte element
Nesting i native CSS kan fuldstændig ændre, hvad vælgeren faktisk betyder (dvs. vælger et helt andet element).
Overvej for eksempel følgende HTML:
<divclass="dark-theme">
<divclass="call-to-action">
<divclass="heading"> Hellodiv>
div>
div>
Og følgende CSS:
body { font-size: 5rem; }
.call-to-action.heading {
.dark-theme & {
padding: 0.25rem;
background: hsl(42, 72%, 61%);
color: #111;
}
}
Dette er resultatet, hvis du bruger Sass som CSS-kompiler:
Nu i HTML-blokken, hvis du skulle flytte med klassen af mørkt tema inde i det af opfordring til handling, ville det bryde vælgeren (i Sass-tilstand). Men når du skifter til almindelig CSS (dvs. ingen CSS-forprocessor), vil stilarterne fortsætte med at fungere.
Dette er på grund af den måde, som :er() virker under motorhjelmen. Så ovenstående indlejrede CSS kompileres til følgende almindelige CSS:
.dark-theme:is(.call-to-action.heading) {
/* CSS code */
}
Dette specificerer en .overskrift det er en efterkommer af begge .mørk-tema og .opfordring til handling. Men rækkefølgen af disse betyder ikke rigtig noget. Så længe .overskrift er efterkommer af .opfordring til handling og .mørk-tema, det virker i begge rækkefølge.
Dette er en kantsag og ikke noget, du vil støde på så ofte. Men at forstå :er() selectors underliggende funktionalitet kan hjælpe dig med at mestre, hvordan nesting fungerer i CSS. Dette gør også fejlretning af din CSS meget nemmere.
Lær hvordan du bruger Sass i React
Fordi Sass kompilerer til CSS, kan du bruge det med stort set enhver UI-ramme. Du kan installere CSS-forprocessoren i Vue-, Preact-, Svelte- og - selvfølgelig - React-projekter. Opsætningsprocessen for Sass for alle disse rammer er også ret ligetil.
Den største fordel ved at bruge Sass i React er, at det lader dig skrive rene, genbrugelige stilarter ved hjælp af variabler og mixins. Som React-udvikler vil vide, hvordan man bruger Sass, hjælpe dig med at skrive renere, mere effektiv kode og gøre dig til en bedre udvikler generelt.