Som du vil ha samlet fra de forrige oppføringene i denne serien, handler PostCSS om pluginene. Pluggene du velger, vil definere din erfaring med PostCSS helt.
Gitt at de er så integrerte og grunnleggende, før vi går videre til å faktisk produsere stilark via PostCSS, skal vi se på hvordan du kan utforske PostCSS plugin-økosystemet. Gjennom dette får du også en oversikt over hvor kraftig PostCSS er, og hvordan den tilbyr funksjonalitet som ikke kan lages på samme måte gjennom andre eksisterende midler.
Vi dekker hvor du kan gå for å holde faner på de nyeste og beste pluginene, kategoriene disse pluginene vanligvis faller inn i, og overveielser for hvordan du laster alle disse pluginene inn på prosjekter på en logisk måte.
Når du begynner å jobbe med PostCSS, er det tre steder du vil holde øye med for å finne gode plugins.
Hovedsiden til PostCSS Github repo opprettholder for tiden en omfattende kategorisert liste over plugins. Denne listen har en tendens til å bli oppdatert ofte, så det er ganske pålitelig sted å gå og se hvilke plugins som er tilgjengelige for ulike aspekter av utviklingen.
https://github.com/postcss/postcss#pluginsEn relativt ny, og veldig velkommen, tillegg til PostCSS verden er siden postcss.parts, som gir en søkbar katalog av PostCSS plugins.
http://postcss.partsAkkurat nå ser PostCSS en ny og interessant plugins ut på jevne mellomrom. Ovennevnte to steder markerer ikke nye plugins, så et øyeblikk vil du ikke vite om det finnes elementer du ikke har sett før. Av den grunn er det en god ide å følge eller ofte besøke @PostCSS på Twitter.
https://twitter.com/postcssBredden av funksjonalitet i plugins som kan fungere med PostCSS er enorm, så det er en god ide å ha en introduksjon til den generelle typer av plugins du sannsynligvis vil støte på før du beveger deg inn i å prøve noen av dem.
PostCSSs grunnleggende natur er at den gir modulær CSS-behandling. Som sådan oppfordres individuelle plugins til bare å dekke et lite, tett definert sett med funksjonalitet. Megalitiske multifunksjonsplugins som gjør alt på en gang, er motet.
Når det er sagt, noen ganger vil du inkorporere en lang liste over funksjonalitet i et prosjekt, og du vil heller ikke måtte installere og konfigurere 20 forskjellige plugins. Det er her "pakker" kommer inn i spill. Pakker samler flere modulære plugins under en tematisk paraply, slik at alle kan installeres og distribueres samtidig.
For eksempel kombinerer PreCSS-pakken ni separate PostCSS-plugins for å skape Sass-lignende funksjonalitet. Cssnano-pakken bruker rundt tjue PostCSS-plugins for å gi CSS-reduksjon og optimalisering. Ved å bruke disse pakkene lagrer du selv å måtte installere og laste hver plugin manuelt.
Fremtidig CSS handler om å la deg skrive syntaks vi vet kommer opp i W3C-spesifikasjonen, men kan ikke støttes fullt ut i nettlesere ennå.
For eksempel vil du kanskje kunne bruke den kommende åtte eller fire sifrede hexidekimale notasjonen for å skape ugjennomsiktige farger. For å generere en litt gjennomsiktig blå kan du bruke en fargekode som # 0000ffcc
, eller dens forkortede form # 00fc
, og kjør postcss-farge-hex-alfa-plugin for å konvertere det til det mye støttede formatet rgba (0, 0, 100%, 0,8)
.
Den mest fremtredende tilstedeværelsen i PostCSS fremtidige CSS er cssnext-pakken, som bringer en hel del spesifikasjonsspørsmål for fremtidig CSS til bordet. Imidlertid tar utvikleren Maxime Therouin i dag pakken gjennom en større overgang i hvordan den fungerer. Som sådan vil vi holde brann på å gi deg en fremtidig CSS opplæring til overgangen er fullført.
Hvor fremtidig CSS handler om å lage morgendagens kodearbeid i dagens nettlesere, fallbacks handler i utgangspunktet om å lage dagens kode i gårsdagens nettlesere. I en perfekt verden ville vi aldri måtte tenke på gamle og utdaterte nettlesere, men virkeligheten er at det fortsatt er noen prosjekter som støtter eldre nettlesere er avgjørende. Fallbacks kategorien av PostCSS plugins kan hjelpe deg der det er tilfelle.
Alle disse pluginene kjører håndfri, som jeg mener at du skriver koden din i henhold til gjeldende standarder, og pluginene vil finne kode som trenger eldre tilbakemeldinger og automatisk sette dem inn etter behov.
For eksempel kan du ha flate farger lagt inn som fallbacks for RGBA ()
farger ved postcss-color-rgba plugin, eller legg til IE8-kompatible fallbacks for opasitet
via plug-in-opacity-plugin. Den mest kjente av disse pluginene er Autoprefixer, som legger til leverandør prefiks etter behov, basert på data fra CanIUse.com.
Du lærer mer om tilbakekallingsplugger i den kommende "For Cross Browser Compatibility" opplæringen i denne serien.
Språkforlengelsesprogrammer legger til funksjonalitet for CSS som ellers ikke ville være der. Til sammenligning kan du vurdere at de fleste preprosessorer skal være fullt ut av språkutvidelser. Faktisk vil brukerne av Sass, Stylus og LESS trolig føle seg ganske hjemme med mange PostCSS-språkutvidelser, for eksempel de som legger til mixins, variabler, conditionals, loops, nesting, utvide og så videre.
Fordi PostCSS er helt fleksibel, er det også språkutvidelser som tilbyr funksjonalitet som ikke finnes i preprosessorer. For eksempel legger postcss-bem-plugin til syntax spesielt for å lage CSS som følger BEM / SUIT-metoden, (mer om det i en senere opplæring). Postcss-define-property plugin lar deg lage dine egne egendefinerte egenskaper, eller omdefinere innfødte egenskaper. Og plug-in-plug-in-modulen lar deg bruke ikke bare betingede, men mønster-matching logikk i koden din.
Med denne variasjonen er alle indikasjoner at PostCSS vil modnes til det punktet hvor det kan gi mye av funksjonaliteten mange av oss ser etter i preprosessorer, men også betydelig funksjonalitet utover det.
Mange av fargepluggen som nå er tilgjengelige for PostCSS, omhandler omforming av farger fra ett format til et annet, for eksempel fra # hex.a
til RGBA ()
, HCl (H, C, L)
til #rgb
, eller pantone til #rgb
. I tillegg til dette, håndterer noen av de mest nyttige pluginene fargemanipulering, for eksempel å blande to farger, eller skalere lysheten eller mørket av dem.
En bestemt favoritt av meg tillater deg å ta ditt eksisterende fargevalg, og deretter utgjøre en versjon som det ser ut til folk med bestemte former for fargeblindhet. Det er ingenting som å oppleve noe førstehånd for å hjelpe deg med å måle hvor tilgjengelig dine design er.
Vi vil gå nærmere på fargeplugger i vår senere preprocessing, shorthand og "diverse goodies" -tutorials.
Denne kategorien plugins håndterer mange optimaliseringsoppgaver, for eksempel pakking av Base64-data, generering av CSS-spriteark og SVG-optimalisering. Du finner også flere andre typer bilde- og skriftverktøy, for eksempel automatisk SVG til PNG-konvertering for IE8, automatisk WebP-bildegenerering og inkludering for støttende nettlesere, @ Font-face
snarveier, retina snarveier og mer.
Oppdage at nettverkssystemene kan skrives i PostCSS, uten å måtte laste forhåndskrevne stilark eller bruke preprocessor mixins, var det første som virkelig åpnet øynene mine med hensyn til hvor kraftig PostCSS er. Jeg hadde tidligere trodd at PostCSS primært handlet om å filtrere og modifisere eksisterende CSS, men grid-systemer viser at det kan brukes til å lage hele biblioteker av eksterne stilarter.
Det finnes for tiden tre grid-systemer tilgjengelig for PostCSS:
PostCSS optimalisering plugins faller inn i to generelle kategorier: minifisering og kode modifikasjon. Gjennom disse pluginene kan du utføre minifiseringsoppgaver som å strippe mellomrom og kommentarer, og du kan også ha mer komplekse modifikasjoner gjort som å kombinere matchende medieforespørsler, inlining @importere
stilark, optimalisering av skriftvekter, fjerning av tomme eller dupliserte regler og så videre.
Vi vil dekke mer om denne kategorien av PostCSS-plugins i den kommende "For Minification and Optimization" opplæringen.
Som forprosessor bruker jeg alltid en av de største fordelene var muligheten til å kutte ned på koden jeg måtte skrive gjennom ved hjelp av variabler og mixins. Gjennom PostCSS har jeg oppdaget enda mer omfattende metoder for å gjøre kodeskriving mer effektiv via den lange listen over snarveier og korttilleggsplugger tilgjengelig.
Du kan velge å bruke stenografi for egenskaper, enten du definerer din egen eller bruker eksisterende stenografi, for eksempel w
i stedet for bredde
, h
i stedet for høyde
og så videre. Du kan skrive ut @ Font-face
kode, forvandle
kode, trekanter og sirkler alt i en linje hver. Og du kan snarvei alle slags vanlige oppgaver, inkludert link styling, sentrering, clearfixing, posisjonering, størrelse, avstand og utskrift av fargekoder.
Vi vil gå inn i disse pluginene i dybden i "Shortcuts and Shorthand" opplæringen.
PostCSS kan også brukes til mer enn å transformere CSS, det kan også brukes til å gi tilbakemelding når du utvikler CSS. Noen av de tilgjengelige analyse- og rapporteringspluggene inkluderer en linter for BEM / SUIT-kode, et plugin for å gi deg en oversikt over koden din via CSSstats, "DoIUse" for å fortelle deg hvordan koden din strekker seg med data fra Kan jeg bruke, og en Modernizr filgenerator.
Det er noen flotte PostCSS-plugins som ikke passer helt inn i en bestemt kategori, men er altfor gode til å passere. For eksempel har vi postcss-stil-guide som automatisk genererer en stilguide basert på CSS. Det er også rtlcss plugin, brukt av WordPress, som genererer en rett til venstre versjon av stilarket ditt.
Vi vil dekke noen av disse flotte pluginene i opplæringen "Miscellaneous Goodies".
Den "morsomme" kategorien inneholder slike perler som postcss-spiffing som lar deg bruke UK stavemåte, for eksempel farge
i stedet for farge
, og velmodnet syntax som !vær så snill
i stedet for !viktig
.
Du er usannsynlig å se noen av denne kategorin plugins som brukes i et ekte prosjekt, men en ekte fordel de tilbyr er å fungere som lett forståelige eksempler for aspirerende plugin-utviklere. Å være ganske enkel og kort, de er perfekte for å ta en titt inni og se det som er viktig for hvordan PostCSS-plugins er laget.
En av hovedhensynene du må gjøre når du laster opp rekke PostCSS-plugins, er rekkefølgen der du kjører dem. Du må pause og tenke gjennom listen din, og avgjøre om en plugin kan trenge å kjøre etter en annen for å gjøre det du vil ha det til.
For eksempel kan du bruke et plugin som postcss-simple-vars som legger til støtte for variabler, og du kan bruke den til å lagre en RGBA ()
verdi slik:
/ * kildekode * / $ farge: rgba (0, 0, 0, 0,5); .style bakgrunn: $ color; / * kompilerer til: * / .style bakgrunn: rgba (0, 0, 0, 0,5);
Du vil kanskje også bruke et plugin som postcss-color-rgba-fallback for å legge til en flat heksekode som en tilbakebetaling, noe som gir deg:
/ * kompilerer til: * / .style bakgrunn: # 000; bakgrunn: rgba (0, 0, 0, 0,5);
I dette tilfellet må du sørge for at du kjørte variablene før tilbakekallingspluggen.
Hvis du kjørte fallback-plugin først, ville det bare finne bakgrunn: $ color;
i CSS og ikke vet at det var en RGBA ()
verdi for det å jobbe med.
Men ved å kjøre variablene plugin først, når fallback plugin kjører det vil finne bakgrunn: rgba (0, 0, 0, 0,5);
og fortsett og legg til i ønsket tilbakebetaling.
Lastordren for plugin er noe som vil forandre seg med hvert sett med plugins, så du kan finne at du bare trenger å gjøre litt eksperimenter noen ganger for å få alt som fungerer fint sammen.
For å oppsummere å utforske PostCSS-plugins:
Vi har fullført vår "Quick Start" -guide til PostCSS, og vi er klare til å hoppe inn i det praktiske og begynne å produsere noen faktiske CSS-koden.
I neste veiledning begynner vi hvordan du bruker PostCSS til å generere kryssbrowser-kompatibel kode ved hjelp av automatisert innsetting av leverandørprefikser, og en rekke fallbacks for egenskaper med eldre nettlesere, spesielt IE8.
Se deg i neste opplæring!