Med all snakket i det siste om endelig å kunne bruke CSS Grid, fikk det meg til å tenke: Hvilke andre fantastiske CSS-funksjoner kan jeg bruke nå? CSS Variables var den som umiddelbart sprang i tankene.
Det har vært en stund siden jeg har hørt noe om CSS Variables, og det legger til et helt nytt verktøysett og en måte å tenke på utviklingen av frontenden som spenner meg.
CSS Variabler har banket rundt i noen år nå, men synes ikke å være i stor bruk. Med populariteten til forprosessorer som Sass, klarte frontend-utviklere den variabla kløen for lenge siden.
Jeg var først opphisset av CSS Variables i rundt 2014 og siden da har de dyppet inn og ut av interessesfæren min. Jeg vurderer nå bare å få dem til produksjonssteder, og jeg skal vise deg hvor enkelt og enkelt de skal bruke.
Deklarering av egendefinert eiendom er enkel: Vi trenger bare å opprette eiendommen vi ønsker og legge til to bindestreker til begynnelsen av den. Disse kan deklareres hvor som helst, men legger dem til: rot ser ut til å være en god tilnærming for øyeblikket.
--my-reusable-value: 20px;Å bruke eiendommen er ganske enkelt også. Vi får tilgang til den gjennom var () -funksjonen og bruker eiendommen vi erklærte over.
padding: var(--my-reusable-value);Er det ikke så enkelt og strålende?
CSS-variabler er enkle å bruke og ganske enkelt å huske. Den største utfordringen med CSS Variables (som med de fleste CSS) er å vite riktig tidspunkt og sted å bruke dem. Å kaste dem i tilfeldig rekkefølge er en sikker brann måte å skape et rot av et stilark, og med disse variablene som blir kastet i feilsøking, blir det sannsynligvis vanskeligere.
Riktig bruk saker og strategier for å bruke dem bør vurderes, og dette er hvor de fleste av innsatsen din bør være fokusert.
I det følgende eksemplet skal jeg vise deg et grunnleggende eksempel på hvordan jeg for tiden bygger en responsiv komponent ved hjelp av Sass-variabler. Da vil jeg vise deg hvordan det kan forbedres med CSS Variables på en måte som ikke er mulig med en forprosessor. Dette er et spesifikt brukstilfelle som ikke gjelder for hver vei variabler brukes, men skal vise hvordan CSS-variabler kan brukes forskjellig.
Se pennen CSS-variabler - responsivt brukstilfelle uten CSS-variabler av Adam Hughes ( @lostmybrain ) på CodePen .
Når du bruker Sass, er det noen forskjellige metoder jeg har prøvd. Min nåværende gå til versjonen plasserer medieforespørsler i CSS-blokkene jeg vil endre. Her kan jeg bruke en variabel, standard CSS, mixin eller en utvidelse til å endre dette elementet uten å sprede stilene for komponenten overalt.
Et problem med dette har flere medieforespørsler og mange variabler som er slags relaterte men ikke. Jeg kunne bruke kart for variablene som ville gi mer organisasjon, men jeg tror hovedproblemet er at vi bruker flere variabler for å definere en eiendom. Dette føles bare feil.
Sass-variabler blir brukt på forhånd, noe som betyr at vi må planlegge hver vei vi skal bruke dem. De gjør det lettere å utvikle, men teknisk gir oss ikke noen nye supermakter.
Se pennen CSS Variabler - responsivt bruk tilfelle av Adam Hughes ( @lostmybrain ) på CodePen .
CSS-variabler trenger ikke å bli erklært foran, de er dynamiske. Dette er nyttig på en helt annen måte. Vi kan nå betinget forandre variabler fra hvor som helst og i bestemte sammenhenger, for eksempel medieforespørsler.
Ved å betjene våre spørreskjemaer for media rett opp fra, kan vi redusere mengden medieforespørsler spredt rundt for responsiv styling. Det gir også en veldig fin og ren måte å se generell avstand og typografi styling på tvers av forskjellige formater.
Jeg tror responsive design og temaer er to gode brukstilfeller for CSS-variabler, men det er så mange muligheter.
Sass-variabler og CSS-variabler er to forskjellige dyr, hver med egne pro's og con's.
På grunn av Sasss popularitet og den mer programmatiske naturen til Sass, har mer dybde organisasjonsmønstre utviklet seg over tid. Jeg liker spesielt sass kart og kombinerer lignende type variabler i kartene. Farger, størrelser og snarveier for stier synes å være populære valg for å inkludere i kart.
På grunn av den relativt mindre bruken av CSS-variabler, har de beste metodene ennå ikke utviklet seg. Kart og arrays er ikke mulige på samme måte i CSS, slik at disse nye organisasjonsmønstrene må nyskapende og løse problemene på en annen måte enn Sass.
CSS-variabler håndteres dynamisk av nettleseren ved kjøring, mens Sass-variabler brukes når CSS er kompilert.
Dette er kjernevalgspunktet for CSS Variables for meg. Det vil være interessant å se hvordan folk bruker denne funksjonen over tid, og om det vil leve opp til sitt potensial.
Jeg er personlig av den oppfatning at jo flere ting vi kan fjerne fra Webpack , Gulp , og hva som helst-nytt-rammeverk-er-ute-nå , jo bedre. Å ha interessante nye nettleserfunksjoner betyr at vi ikke trenger å stole på kompilering og JavaScript-rammer for å gjøre ting utviklere føler er avgjørende. Jeg ville risikere en gjetning at en høy prosentandel av frontend-utviklere bruker variabler i deres CSS på en eller annen måte, slik at alle som bruker dette er en kjernefunksjon, virker som en fornuftig ting å gjøre. Det betyr en mindre ting i byggesteget (som jeg tror vi alle kan være enige om, blir ganske enorm i disse dager) og mer konsistens på tvers av nettet.
Støtten ser bemerkelsesverdig godt ut med et skarpt unntak: IE 11. De fleste moderne nettlesere støtter CSS Variables with Edge med noen få feil.
På 78,11% er dette høyere enn CSS-nettverket (på tidspunktet for skriving), men at IE11-støtte kan være et problem.
Jeg tror tiden er nå. At IE11-støtten ikke kommer til å bli bedre, og vi vet fra tidligere versjoner av Windows at det tar lang tid for noen mennesker å oppgradere. Men støtten på tvers av moderne nettlesere er stor, noe som betyr at vi bør se etter CSS-variabler og eksperimentere med mulighetene.
Det betyr ikke at vi ikke bør glemme vårt ansvar til eldre nettleserstøtte skjønt. Et grunnleggende fallback-system som bruker en støttemerker, eller til og med en polyfil, for eldre nettlesere, bør overveies, enda mer hvis din faktiske bruk av nettstedet er mye mer skjev til eldre nettlesere.
Det er en spennende tid for utvikling av frontender, og jeg kan ikke vente på å bruke flere av disse teknologiene på mine produksjonssteder.