Utenfor i - Bestilling av CSS Properties etter betydning

Denne artikkelen handler om CSS-kodestruktur - spesifikt om en metode jeg har brukt de siste årene for å få noen logikk og konsistens til ordren der jeg skriver min CSS. Det er en metode jeg kaller "Utenfor I".

Deklarasjonsordre?

Jeg har hørt om ulike tilnærminger til å skrive CSS tidligere. Noen mennesker bruker ikke noen bestemt ordre i det hele tatt, andre alfabetiske erklæringer etter eiendomsnavn, jeg har selv hørt om en håndfull tilfeller hvor noen bestiller dem visuelt av lengden av hver Eiendomsverdi par! 

En tidligere undersøkelse på CSS-Tricks spurte dette spørsmålet med et resultat som jeg fant ganske overraskende: 39% av over 11.000 mennesker har ingen bestemt plan når det gjelder å bestille CSS.

Hvordan bestiller du CSS-egenskapene dine? Totalt antall stemmer: 11,093

Gruppering etter type kan foreslå høyde være ved siden av bredde. Alfabetisk ville se deklarasjoner oppført fra bakgrunn gjennom til z-indeks, for eksempel.

Jeg bruker metoden for å gruppere egenskaper etter type - selv om jeg selv bruker en bestemt ordre for bestilling etter gruppe!

Med unntak av "tilfeldig metode" er det noen grad av orden i alle de andre tilnærmingene. Men den ordren er ikke nødvendigvis kartlagt godt til noe spesielt nyttig når det gjelder styling av nettsteder. 

Hvis du samler data om elevers høyde i et klasserom, vil det være fornuftig å bestille dem med lengdemåling. Hvis du kategoriserer en samling av DVDer, kan alfabetisk bestilling være fornuftig. Men ville CSS egenskaper bestilt på disse måtene ha noe å gjøre med deres rekkefølge av betydning når de stilene er malt av nettleseren? 

Hvis du bestiller alfabetisk, er et element farge viktigere enn sin bredde? Er et element border-style viktigere enn om det er i den normale strømmen av dokumentet eller ikke? Jeg vil ikke si det.

Utsiden inn

Metoden som jeg har kommet for å elske ordrer CSS egenskaper ved hvor mye effekt de har på de valgte elementene eller andre elementer rundt dem. Kjennetegnet ved teknikken er å starte med storbildede egenskaper som påvirker ting utenfor elementet og arbeider inn mot de finere detaljene. Det er derfor jeg kaller det "Outside In" -metoden.

stilling og flyte erklæringer fjerner elementer fra deres normale strømning og har stor innvirkning på andre elementer rundt dem. Dette er noe viktig, og jeg føler at det bør gjøres klart rett øverst i en blokk med CSS. 

Kontrollerer ting som markør eller flyte av et element er (vanligvis) mindre viktig, og derfor har jeg en tendens til å forlate ting som dette mot slutten. 

Bestillingen jeg bruker er som følger: 

  • Layout Egenskaper (stilling, flyte, klar, vise)
  • Boksmodellegenskaper (bredde, høyde, margin, padding)
  • Visuelle egenskaper (farge, bakgrunn, grense, box-shadow)
  • Typografi Egenskaper (skriftstørrelse, font-family, tekst-Juster, text-transform)
  • Diverse egenskaper (markør, flyte, z-indeks)

jeg vet det grense er en bokmodell eiendom og z-indeks er relatert til posisjon, men denne bestillingen fungerer for meg. Selv om jeg ikke liker alfabetisk bestilling, er det noe som bare føles riktig om å sette z-indeks på slutten…

Praktisk eksempel

La oss ta et eksempel på styling av en knappmodul. 

La oss starte med et hyggelig, meningsfylt klassenavn som .knapp. Jeg personlig misliker kontrakterte navn som .btn og pleier å favorisere lange, beskrivende klassenavn der det er mulig - det er bare en personlig preferanse, YMMV :)

/ * Bestill nå → * / .button 

Vi ønsker å kunne manipulere vertikal avstand rundt knappen, så det må endres vise fra på linje (standard for ankerforbindelser) til inline-blokk

For å tillate at knappen vokser i bredden avhengig av tekstinnholdet, inline-blokk er et mer fleksibelt valg enn flyte med en bredde sett.

.knapp display: inline-block; 

Deretter må vi legge til noen bokmodellegenskaper som margin og polstring. Marginen går utenfor boksen, så går "Outside In", bør dette komme først.

.knapp display: inline-block; margin: 1em 0; polstring: 1em 4em; 

De neste tingene du vil legge til er fargene. For å skille ut hver gruppe eiendomstyper, liker jeg å legge en tom linje - dette gjør hver seksjon skiller seg ut mye mer.

.knapp display: inline-block; margin: 1em 0; polstring: 0.5em 3em; farge: #fff; bakgrunn: # 196e76; 

Deretter kan vi legge til i grenser og skygger for å gi noe dybde, etterfulgt av noen typografiegenskaper, igjen adskilt av en tom linje.

.knapp display: inline-block; margin: 1em 0; polstring: 1em 4em; farge: #fff; bakgrunn: # 196e76; border: 0.25em solid # 196e76; boks-skygge: innspill 0.25em 0.25em 0.5em rgba (0,0,0,0,3), 0,5em 0,5em 0 # 444; font-size: 3-em; font-familie: Avenir, Helvetica, Arial, sans-serif; tekst-Justering: center; text-transform: store bokstaver; text-decoration: none; 

Lesingskode

En fordel ved å ha et system som dette er at det fjerner behovet for å tenke for mye når det er implementert. Hvis jeg leser gjennom koden min og vil endre noe stort bilde som et element bredde eller stilling, Jeg vet at jeg skal se på toppen av en regel. Hvis jeg vil justere noe sånn text-transform eller list-style, Jeg skal se mot bunnen av blokken.

Å ha koden strukturert som dette er også virkelig hånd for andre som leser CSS; hvis den står overfor en kode som er organisert som dette, er det veldig enkelt å se alle komponentene som utgjør en knappmodul. Når du skriver kode, er det viktig å gjøre det så enkelt som mulig for våre medarbeidere å lese; Dette gjør koden lettere å forstå og vedlikeholde.

preprocessors

Jeg har brukt vanilje CSS til å forklare metodene mine her, men du kan bruke "Outside In" -tilgangen like effektivt i Sass, LESS og Stylus.

Konklusjon

Koding kan være en veldig personlig ting. Hvis du bruker en annen metode for å organisere CSS, ville det være flott å høre om det! Legg igjen en kommentar for å fortsette diskusjonen.