11 ting, jeg lærte at læse CSS Grid Specification

Illustration af Alex Kunchevsky

11. juni 2017 besluttede jeg at læse CSS Grid spec.

Specifikationen var lidt teknisk, men det var langt den mest nydelige specifikation, jeg nogensinde havde læst. Hvis du er en mere avanceret udvikler, skal du bogmærke den til fremtidige referencer.

Så vil dette være nyttigt?

Jeg tror, ​​at forskellen mellem gode og gode ingeniører er, at sidstnævnte tager sig tid til at forstå, hvad der virkelig foregår under hætten. De lærer, hvordan tingene fungerer, i stedet for at lære ved at "kopiere og indsætte."

Så ønsker du at være en god udvikler?

Helvede ja. Eller du skulle ikke læse denne artikel.

Hvad du lærer

Mens jeg læste spec, lærte jeg nogle meget subtile, men dybe detaljer.

I denne artikel vil jeg dele dem med dig.

1. CSS Grid er erklærende

Deklarative API'er er så søde at arbejde med. Tænk ReactJS?

Da websteder udviklede sig fra enkle dokumenter til komplekse, interaktive applikationer, blev weblayouts vanskeligt at komponere. Så vanskelige, de var mit mareridt.

Dette er nøjagtigt problemet CSS Grid er kommet til at løse i dag.

Fra spec.

CSS Grid fjerner den smertefulde proces med at udforme intelligente layouts og erstatter den med et smukt sæt af deklarative regler, der gør processen nær ubesværet.

Dette er gode tider i CSS 'historie.

2. Fraktionenheden producerer ikke altid rækker og søjler med lige stor afstand

En af de første ting, alle lærer og elsker at få med CSS Grid, er brøksenheden. Selv en and kan slippe af med det.

Fraktionenheden fjerner smerten ved beregning af procentdel. Det er en fryd at arbejde med.

De fleste mennesker lærer, at brøksenheden (fr) giver lige store indbyrdes fordelte søjler eller rækker.

For eksempel forventes en erklæring som 1fr 1fr 1fr at give dig kolonner eller rækker med samme afstand. Se illustrationen nedenfor:

Søjler med lige stor afstand er oprettet af brøksenheden.

Desværre er dette IKKE altid sandt. Stakkels and.

Følgende er fra specifikationen:

Fr-enheden fylder den disponible plads MEN den er ALDRIG mindre end minimumsstørrelsen på gitterbeholderen eller indholdet af rækken eller søjlen.

I det væsentlige, hvis du har et billede, en img eller et hvilket som helst gitterelement med en min-bredde eller min-højde-erklæring, kan du få uventede resultater med brøksenheden.

Efter at have kvædet rundt som en våd bange and, tilbragte jeg megen tid på at eksperimentere med den brøkdelte enhed. Jeg skrev en artikel om mine fund.

3. Du ved ikke rigtig, hvordan Grids er størrelse. Eller gør du det?

En CSS-netdefinition begynder altid i linjerne i dette:

display: gitter

Ofte følges det af række og kolonne definitioner. Noget som dette:

gitter-template-rækker: 10px 1fr 3fr
gitter-skabelon-kolonner: 1fr

Og endelig er det sandsynligt, at du placerer netværkene, uanset hvilken teknik der passer dig.

Da der er mange måder at placere gitterelementer på, springer jeg den nødvendige kode over for kortfattethed.

Så her er problemet.

Under hætten skal du antage, at størrelsen på gitterrækker og -søjler først beregnes, før emnerne placeres. Ret?

Det ser ud til, at sandheden er den modsatte.

Hvor underligt.

Følgende er fra specifikationen:

2.3. Størrelse på gitteret
Når gitterelementerne er placeret, beregnes størrelserne på gittersporene (rækker og kolonner), idet de tager højde for størrelserne på deres indhold og / eller den disponible plads som specificeret i gitterdefinitionen.

Bemærk progressionen.

  1. Gitterelementerne er placeret.
  2. Størrelserne på gitterbanerne beregnes

Du har sandsynligvis spørgsmål omkring dette. Så jeg vil prøve at løse dine bekymringer.

Bemærk for det første, at hvert gitterelement tildeles et gitterområde. Gitterelementerne er derefter dimensioneret inden for dette område. Så hvordan nøjagtigt er gitterelementerne anbragt uden allerede at beregne størrelsen på sporene?

Hvis du kigger på afsnittet om placering af gitterelementer i specifikationen, finder du en anelse.

Der tages meget i betragtning ved størrelsesstørrelse af gitter, og det inkluderer i vid udstrækning størrelsen på gitterelementerne.

Størrelsesgitter kan være baseret på følgende:

  • En fast dimensioneringsfunktion (længde eller opløselig procentdel).
  • En iboende størrelsesfunktion (min-indhold, max-indhold, auto, fit-content ()) eller
  • En fleksibel størrelsesfunktion (flex).

Hvad jeg tror, ​​der sker under hætten, er, at gitterartiklerne er placeret.

Det vil sige, den indeholdende blok for emnet bestemmes, størrelsesfunktionen for emnet bestemmes derefter. Dette påvirker igen størrelsen på gitterbanerne.

Du ser?

Ikke hvad du oprindeligt troede.

4. Som standard strækkes gitterelementer til at passe til deres gitterområde - undtagen i visse tilfælde

Uden din indgriben strækker gitteremner altid sig, så de passer til deres gitterområde.

Så hvis du havde en erklæring sådan:

grid-template-områder: 'header header header'
                     'sidebar main main'
                     'sidefod sidefod fod'

Og du havde divs tildelt til de specifikke gitterområder, som sådan:

.div1 {
   gitter-område: header
}
.div2 {
   gitterområde: sidebjælke
}
.div3 {
   gitterområde: hoved
}
.div4 {
   gitterområde: sidefod
}

Du behøver ikke at erklære bredden og højden af ​​divserne over til 100%

De strækker sig automatisk for at udfylde deres respektive områder.

Her er fangsten.

Denne opførsel er i strid med billeder.

Som påpeget af Rachel Andrew, fortæller specen, at denne opførsel er forskellig for netelementer med et iboende billedforhold.

Lad ikke de store ord skræmme dig. Det er ikke nogen demogorgon.

Et billede er som standard et inline-block-element, men de har også specifikke dimensioner. De har dimensioner, der naturligvis er forbundet med dem. Et billede kan være 400px x 600px bredt eller en hvilken som helst given dimension overhovedet.

Men regelmæssige blokelementer som divs har ingen indre dimensioner. Det vil sige, de har ikke dimensioner, der naturligt hører til dem.

Selvom gitterelementer med NO-iboende dimensioner strækker sig for at passe til deres gitterområde, er dette ikke tilfældet for gitterelementer, der har en indre dimension, f.eks. Billeder.

5. Ved du virkelig, hvad et netværk er?

Overvej kodeblokken nedenfor:

    
blok     
flyde         Jeg er en tilfældig tekst              punkt 4     

Kan du få vist gitterelementerne i kodeblokken ovenfor?

Hvor mange gitterelementer er der i kodeblokken, 3 eller 4?

Jeg mislykkedes dette spørgsmål åbenlyst.

Bemærk, at teksten, jeg er en tilfældig tekst, ikke er indpakket af nogen HTML-tags.

hvilken er det?

Så hvad er dit svar?

Nå, hvis du svarede 3, har du forkert. Haha, har du det!

Ifølge specifikationen indpakkes et anonymt gitterelement rundt om hver tekstrække i et gitter.

Ja, det betyder, at jeg er en tilfældig tekst, er også et gitterelement.

blok     
flyde
    
    Jeg er en tilfældig tekst

    
        punkt 4
    

Ja, svaret er 4. Vi har 3 eksplicit rutenetværker og 1 anonym gitterpost!

Forstået?

6. Margenerne på tilstødende gitterprodukter kollapser ikke.

Der er store forskelle mellem blokelementer og gittercontainere.

Hvad jeg mener er, et element med display: blok og et andet med display: gitter har en masse grundlæggende forskelle.

Den forskel, jeg vælger at diskutere her, har at gøre med sammenklappelige marginer.

En af de første ting, du lærer med CSS, er begrebet sammenklappelige marginer. Jeg ønsker ikke at bruge meget tid på at forklare, hvad sammenklappelige marginer betyder. Hvis du bringer det op i kommentarerne, gør jeg det.

Så tilbage til gitre.

For hver gitterpost kollapses marginerne aldrig.

Dette er forståeligt. Lad mig vise dig hvorfor.

Tilstødende gitterelementer er uafhængigt indeholdt i den indeholdende blok, der dannes af deres gitterområder.

Hvad det komplekse afsnit ovenfor betyder er dette. Hver gitterpost lever og ånder i et gitterområde

Gitterposter placeres inden for deres respektive gitterområder. De forbliver i deres egne uforstyrrede områder. De påvirkes ikke af sammenklappelige marginer. Hvor sej.

Teknisk set kan du måske sige, at gitterelementet ikke er en umiddelbar nabo til de andre gitterelementer. Men er indeholdt i et uafbrudt lukket territorium - gitterområdet.

Hvis du er nysgerrig efter, hvilke andre forskelle der findes mellem blokelementer og gitterelementer, skrev jeg en interessant artikel om emnet.

7. automatisk udfyldning og automatisk tilpasning. Hvad er forskellen?

Selvom automatisk udfyldning og automatisk tilpasning ligner de samme funktioner, er de forskellige på en måde.

De er ens i den forstand, at de giver mulighed for automatisk at oprette gitterspor, der fylder gitterbeholderen på en eller anden måde.

F.eks. Opretter følgende kode så mange 200px-kolonner, der passer ind i vinduesbredden. Hvis der er noget tilbage, vil det blive fordelt på 200px-kolonnerne.

krop {
  display: gitter;
  gitter-template-kolonner: gentag (automatisk udfyldning, minmax (200 px, 1fr));
}

Hvad er forskellen?

automatisk udfyldning opretter spor, selvom der ikke er noget gitterelement til at udfylde det. auto-fit vil ikke gøre dette. Det vil tømme tomme spor til nul.

Det er alt.

8. I definitionen af ​​rist-skabelon-områder SKAL antallet af ord i en streng være lige.

Kan du huske de underlige udseende værdier for gitter-skabelonområder, der ligner et kort?

Det ser ud til, at det kan røre ting hurtigt hurtigt.

I en gitter-skabelon-områdedeklaration skal alle strenge have det samme antal kolonner, ellers er erklæringen ugyldig.

For eksempel:

/ * dette er gyldigt * /
grid-template-areas: "header header sidebar"
                     "main main main sidebar"
                     "main main main sidebar"
/* det er forkert */
grid-template-areas: "header header sidebar"
                     "main main main sidebar"
                     "vigtigste hovedbjælke"

Antallet af ord i strengene skal være ens.

9. Undgå at bruge procentsatser i polstringer eller margener på netelementer helt

Fra CSS Grid Spec

Årsagen bag dette er enkel. På dette tidspunkt får du forskellige opførsler i forskellige browsere.

I henhold til specifikationen kan procentdelen opløses enten mod elementets bredde eller venstre / højre marginer mod bredden, mens top / bund er opløst mod højden

For at have en jævn gengivelse på tværs af de fleste browsere skal du undgå at bruge procenter i polstring eller margener på gitterelementer.

Mere vigtigt er, at der allerede er et par forvirrende bits med CSS Grid. Du må ikke skyde dig selv i foden med procentdel polstringer eller marginer i gitterposter.

10. Hvordan løses størrelsen på det eksplicitte gitter, når der er en konflikt?

Antag, at du har en netdeklaration sådan:

grid-template-areas: "header header sidebar"
                     "main main main sidebar"
                     "main main main sidebar"

I kodeblokken ovenfor har du 4 kolonner og 3 rækker.

Hvad hvis du også gjorde dette:

grid-template-kolonner: gentag (5, 1fr)
gitter-template-rækker: gentag (4, 1fr)

Nu har du flere kolonner og rækker. 5 kolonner og 4 rækker.

Har du det?

Der er nu en konflikt i erklæringerne. Så hvordan løses dette?

I henhold til specifikationen bestemmes størrelsen på det eksplicitte gitter af det største af antallet af rækker / kolonner defineret af gitter-skabelonområder og antallet af rækker / søjler, der er størrelse efter gitter-skabelon-rækker / gitter-skabelon-søjler .

Specifikationen kan se ud som om det komplicerer en enkel ting. Hvad det betyder i almindeligt sprog, vinder erklæringen med det større antal rækker eller kolonner.

I eksemplet ovenfor tager gitteret 5 kolonner og 4 rækker, IKKE 4 kolonner og 3 rækker.

* REDIGERING: Egenskaben gitter-skabelon-områder bruges til at placere gitterelementer på et gitter. Så hvorfor skulle vi have en konflikt i netdefinition? Er det ikke meningen, at gitre skal defineres med kun gitter-skabelon-søjler og gitter-skabelon-rækker egenskaber? Jeg svarer på dette i kommentarafsnittet. Tjek det ud.

11. Størrelsen på gitteret er ikke kun summen af ​​sporstørrelser

Gitterspor henviser til afstanden mellem gitterlinjer.

Selvom dette er enkelt, er det værd at nævne, hvis du har en fast bredde gitter oprettet.

Størrelsen på gitteret kan påvirkes af gitter-række-spalten, gitter-kolonne-spalten og retfærdiggør indhold, justere-indhold. Hvilket desværre også kan tilføje yderligere plads mellem sporene.

Så vær forsigtig, mens du beregner faste bredder i nettet.

BONUS: Vi kan alle bidrage til at gøre DOCS bedre

Fordi jeg er en venlig sjæl, har jeg tilføjet endnu et tip her

Specen blev skrevet af mennesker. Og det sker så, at mennesker kan begå fejl.

Mens jeg læste spec, så jeg en lille skrivefejl.

På det tidspunkt var jeg ikke særlig sikker på, hvad jeg skulle gøre. Så jeg spurgte rundt på Twitter.

Den slags Jen Simmons hjalp med at indgive et spørgsmål på github, og det fik løst.

Så hvad er moralen?

Du kan hjælpe med at forbedre dokumenterne bedre ved at bidrage på en hvilken som helst måde, det er muligt.

Ja dig!

Lad os gøre internettet bedre sammen.

Vil du blive Pro?

Download min gratis CSS Grid-guide, og få også to interaktive Flexbox-kurser i kvalitet gratis!

Sådan mestrer du CSS Grid, og hvad man skal bygge undervejs (Gratis PDF-guide)

Hent dem nu