Share
I den tidligere opplæringen gikk vi gjennom hvordan du bruker den gode preprosesseringspakken "PreCSS". I denne opplæringen kommer vi til å nærme seg PostCSS-basert preprocessing på en annen måte; installere et håndplukket utvalg av plugins for å skreddersy bygge preprosessoren fra grunnen opp.
Jeg skal ta deg gjennom oppsettet av hva jeg personlig finn ut til å være en flott blanding av språkforlengelsesprogrammer. Men når det gjelder å rulle din egen forprosessor, kan du velge å bruke bare noen av pluginene vi dekker her, eller du kan velge ingen i det hele tatt, i stedet å gå med andre alternativer.
Det er skjønnheten i denne prosessen; Du kan ha preprosessoroppsettet ditt, selv om du velger det. Formålet med denne opplæringen er å gi deg praktisk erfaring med å sette sammen en PostCSS preprocessor, og å fylle ut på funksjonene til de tilgjengelige pluginene, slik at du kan bestemme deg selv som du vil bruke.
La oss begynne!
Det første du må gjøre er å sette opp prosjektet ditt for å bruke enten Gulp eller Grunt, avhengig av dine preferanser. Hvis du ikke allerede har en preferanse for den ene eller den andre, anbefaler jeg at du bruker Gulp, da du trenger mindre kode for å oppnå de samme ender.
Du kan lese om hvordan du konfigurerer Gulp eller Grunt-prosjekter for PostCSS i de tidligere opplæringsprogrammene
henholdsvis.
Hvis du ikke vil opprette prosjektet manuelt fra starten, kan du laste ned kildefilene som er vedlagt denne opplæringen, og trekke ut enten det forsynte Gulp- eller Grunt-startprosjektet i en tom prosjektmappe.
Deretter kjører kommandoen med en terminal eller kommandoprompt i mappen npm installasjon.
Denne opplæringen antar at du har fulgt de forrige oppføringene i serien og er nå kjent med hvordan du installerer et plugin i prosjektet ditt og laster det via din Gulpfile eller Gruntfile.
Viktig! Når vi går gjennom, må du laste inn pluginene i Gulpfile / Gruntfile i den rekkefølgen du ser i denne opplæringen. belastningsordre er viktig i PostCSS for å holde alt i gang.
Det aller første stedet vi skal begynne med å sette sammen vår tilpassede forprosessor, er import. Du har allerede sett PostCSS inlining av @importere stilark i de tidligere opplæringsprogrammer for Minifisering og Optimalisering og Preprocessing med PreCSS. Måten importen blir brukt i denne preprosessoren, er ikke annerledes.
Vi har bare rørt over det faktum at belastningsordren er viktig i PostCSS, og her finner vi det første eksemplet på dette. Vi ønsker å sikre alle @importere filer er inlined som det aller første skrittet, slik at vi har all koden til prosjektet vårt på ett sted for resten av pluginene våre til å løpe mot.
For eksempel kan vi lagre alle våre variabler i en delvis fil, og bruk @importere å bringe det delvis inn i vårt hovedformat. Hvis vi ikke kjørte pluginet som inlines @importere filer først, våre variabler ville ikke bli importert og dermed ikke tilgjengelig for resten av behandlingen vår å jobbe med.
Fordi vi skal begynne å importere deler, vil vi gjøre en liten tilpasning til vår Gulpfile før vi legger til vår importeringsfunksjonalitet.
Merk: Hvis du bruker Grunt, trenger du ikke å gjøre noen endringer på dette stadiet.
Akkurat nå har vi en ". Css" -fil som er funnet i "src" -mappen som er kompilert, men vi vil ikke ved et uhell kompilere delvise filer. Vi importerer alt inn i filen "style.css", så det er den eneste som må kompileres.
Finn denne linjen:
Accentsconagua
returner gulp.src ('./ src / *. css')... og endre den til:
returner gulp.src ('./ src / style.css')Dette er det samme pluginet vi brukte i "For Minification and Optimization" opplæringen, og det brukes også i PreCSS, så du vil være litt kjent med det på dette punktet.
Installer pluginet i prosjektet ditt, og opprett deretter en fil med navnet "_vars.css" i "src" -mappen din, og legg til noen grunnleggende testkode til den. Merk at vi ikke har lagt til variabler funksjonalitet ennå, så bare noen rette CSS, for eksempel:
.test bakgrunn: svart;
Importer nå den nye variabelfilen inn i hovedfilen "src / style.css" ved å legge til denne koden på første linje:
@import "_vars";
Kompil koden din og sjekk deretter filen "dest / style.css", og du bør se at den nå inneholder koden fra «_vars.css» -filen din.
Merk: denne plugin må bli utført før de postcss-nestede og postcss-simple-vars plugins, begge som vi skal bruke.
Gå videre og installer postcss-mixins, og legg deretter til følgende kode i filen "src / style.css":
@ define-mixin icon $ network, $ color . knapp. $ (nettverk) bakgrunnsbilde: url ('img / $ (nettverk) .png'); bakgrunnsfarge: $ color; @mixin ikon twitter, blå;Etter samling skal "dest / style.css" ha følgende kompilerte kode lagt til den:
.button.twitter bakgrunnsbilde: url ('img / twitter.png'); bakgrunnsfarge: blå; Postcss-mixins-plugin-modulen vi bruker her er den samme som brukes i PreCSS. Vi gikk over hvordan du bruker den i opplæringen på PreCSS, så for detaljer om sin syntaks, sjekk ut "Mixins" -delen av den forrige opplæringen.
Hvis du foretrekker å bruke Sass-syntaks når du lager mixins, sjekk ut Andy Janssons postcss-sassy-mixins-plugin, som fungerer på samme måte som postcss-mixins, men med syntaksen @mixin å definere en mixin, og @inkludere å bruke en.
Merk: Postcss-for plugin er en annen som må bli utført før postcss-nested og postcss-simple-vars.
Installer postcss-for plugin, og test deretter at det fungerer som forventet ved å legge denne koden til "src / style.css" -filen din:
@for $ i fra 1 til 3 p: nth-of-type ($ i) margin-left: calc (100% / $ i);
Det burde kompilere for å gi deg:
p: nth-of-type (1) margin-left: calc (100% / 1); p: nth-of-type (2) margin-left: calc (100% / 2); p: nth-of-type (3) margin-left: calc (100% / 3);
Igjen, pluginet vi bruker til å legge til @til sløyfer er det samme som i PreCSS, så for å få mer informasjon om sin syntaks, sjekk ut "Loops" -delen i den forrige opplæringen.
Postcss-for plugin må kjøres før postcss-simple-vars, noe som betyr at det ikke er mulig å bruke variabler for å angi rekkevidden du vil ha @til loop for å iterere gjennom.
Hvis dette er et problem, kan du i stedet bruke denne gaffelen til postboks-for plugin som i stedet skal lastes inn etter postcss-simple-vars plugins.
Fordi den går etter at variabler er vurdert, er du fri til å bruke variabler for å angi rekkevidden du vil ha @til loop for å iterere gjennom, slik:
@ fra: 1; @count: 3; @for $ i fra @fra til @count p: nth-of-type ($ i) margin-left: calc (100% / $ i);
Vi skal legge til to typer variabler til vår forprosessor, som begge kan være veldig nyttige. Den første typen bruker Sass-lignende syntaks, og den andre bruker syntaksen til CSS tilpassede egenskaper, ellers kjent som CSS-variabler.
Installer disse to plugins, så vil vi teste hver og en av gangen.
Først skal vi teste Sass-lignende syntaks av postcss-simple-vars. Åpne filen "_vars.css" du har laget tidligere, slett innholdet og legg til følgende kode:
$ default_padding: 1rem;
Legg til følgende i filen "src / style.css" og kompilere:
.Legg inn padding: $ default_padding;
Det burde kompilere for å gi deg:
.post polstring: 1rem;
Nå skal vi teste CSS tilpassede egenskaper som syntaks av postcss-css-variabler. Legg til følgende kode i filen "src / style.css":
: root --h1_font_size: 3rem; h1 font-size: var (- h1_font_size); @media (maksimal bredde: 75rem) h1 --h1_font_size: 4vw;
Det burde kompilere til:
h1 font-size: 3rem; @media (maksimal bredde: 75rem) h1 font-size: 4vw;
Legg merke til at når vi brukte CSS-variabler, måtte vi bare endre verdien av --h1_font_size variabel innenfor mediesøket, og det utløser automatisk den tilknyttede skriftstørrelse eiendom. Dette er spesielt nyttig funksjonalitet.
Før jeg går videre, skal jeg bare kort nevne igjen at tilnærmingen tatt i denne opplæringen ikke er tilnærming du ha å ta. Hvis du vil bruke en slags variabel og ikke den andre, er det helt greit.
Fra mitt perspektiv er grunnen til at jeg liker å bruke begge typer variabler, jeg bruker dem på to forskjellige måter. Jeg vil vanligvis bruke CSS egendefinerte egenskaper syntaks i mitt hovedformatark, mens jeg bruker Sass-lignende variabler i mine delvise filer.
Dette lar meg angi CSS tilpassede egenskaper for typen variabler jeg egentlig kan bruke i et live-prosjekt hvis / når de blir godt støttet på tvers av nettlesere. Som du så i eksemplet ovenfor, har de også visse funksjoner som Sass-lignende variabler ikke gjør.
I mellomtiden kan jeg bruke Sass-lignende variabler for ting som ikke tilhører et levende stilark, spesielt de som eksisterer, bare for å bli behandlet gjennom gjennom ting som hver løkke, conditionals og andre transformasjoner.
Som et alternativ til bruk av postcss-simple-vars kan du vurdere å bruke postcss-advanced-variabler, plugin som brukes som en del av PreCSS-pakken.
Dette er også et utmerket alternativ, med den primære forskjellen at det håndterer conditionals, sløyfer og variabler i samme plugin. For meg er grunnen til at jeg for øyeblikket velger postcss-simple-vars, jeg foretrekker å ha kondisjoner som kommer fra et eget plugin; postcss-conditionals som vi dekker kort tid.
I stedet for å bruke postcss-css-variabler, kan du foretrekke postcss-tilpassede egenskaper.
Den vesentlige forskjellen mellom de to er postcss-tilpassede egenskaper, som er i tråd med W3C-spesifikasjonen for egendefinerte egenskaper, slik at du kan være sikker på at du skriver bare riktig fremtidig CSS. På den annen side gir postcss-css-variabler ekstra funksjonalitet, men på den måten hevder det ikke å ha full paritet med spesifikasjon.
Jeg personlig velger postcss-css-variabler fordi jeg bruker den i sammenheng med preprocessing hvor jeg skriver mye ikke-spesifikasjonskode uansett. Som sådan vil jeg helst ha den ekstra funksjonaliteten over 100% spesifikasjon.
Men hvis du bruker variabler i sammenheng med å skrive fremtidig CSS, kan du finne postcss-tilpassede egenskaper er bedre egnet for deg.
Installer postcss-hver plugin og legg deretter til denne variabelkoden i filen "_vars.css":
$ sosial: twitter, facebook, youtube;
Denne koden definerer en liste, lagret i $ sosial variabel.
Nå skal vi lage en @Hver loop for å iterere gjennom verdiene lagret i vår $ sosial variabel. Legg til denne koden i filen "src / style.css":
@each $ icon i ($ sosial) .icon - $ (ikon) bakgrunn: url ('img / $ (ikon) .png'); Våre @Hver sløyfen er nå klar, men før vi kan kompilere det, må vi gjøre en liten konfigurasjonsendring til alternativene til postcss-simple-vars.
Du merker at i koden ovenfor bruker vi $ ikonet å representere den nåværende verdien vi itererer gjennom. Noen problemer kan oppstå fra dette fordi postcss-simple-vars plugin ser etter $ logg inn for å identifisere variabler.
Dette betyr at det vil se $ ikonet, tror det er en variabel, prøv å behandle det, så se det har ingen verdi. Det vil få det til å slutte å kompilere og logge en feil til konsollen at det er oppdaget en udefinert variabel.
For å løse dette, vil vi legge til alternativet stille: sant til våre alternativer for plugin. Dette betyr at hvis det oppdager en udefinert variabel, vil det ikke slutte å kompilere for å logge en feil, det vil bare fortsette. Derfor vil det ikke bli plaget av nærværet $ ikonet i vår @Hver loop og vi kan kompilere med hell.
I prosessorene i Gulpfile eller Gruntfile, angi alternativet:
/ * Gulpfile * / simple_vars (silent: true) / * Gruntfile * / require ('postcss-simple-vars') (lyd: true)Nå kompilere CSS og du bør få:
.ikon-twitter bakgrunn: url ('img / twitter.png'); .icon-facebook bakgrunn: url ('img / facebook.png'); .icon-youtube bakgrunn: url ('img / youtube.png'); Som nevnt tidligere er postcss-advanced-variabler et annet utmerket plugin-alternativ som håndterer variabler, looper og conditionals alt i ett.
Jeg nevnte tidligere at dette pluginet er min preferanse for håndtering av conditionals. Dette er fordi jeg har funnet at det er i stand til å håndtere mer komplekse betingede kontroller. Det inkluderer støtte for @eller hvis syntaks, noe som betyr at du kan teste mot flere forhold i et enkelt stykke kode.
Etter å ha installert plug-in-betingelsen, test det ved å legge til denne koden i filen "src / style.css":
$ column_count: 3; . kolonne @if $ column_count == 3 bredde: 33%; flyte: venstre; @else hvis $ column_count == 2 bredde: 50%; flyte: venstre; @else bredde: 100%;
Denne koden vil sjekke verdien vi har satt inn i variabelen @column_count og vil sende forskjellige bredde- og flytverdier avhengig av hva den finner. Det fungerer på samme måte som koden vi brukte i forrige forhåndsbehandling, men nå har vi muligheten til å bruke @eller hvis linjer vi har kunnet øke antall forhold vi tester fra to til tre.
Etter omkompilering bør dette gi deg:
.kolonne bredde: 33%; flyte: venstre
Prøv å endre $ COLUMN_COUNT til 2 eller 1 og kompilere igjen for å se hvordan det endrer CSS-utgangen.
Vi kan også bruke disse typer conditionals godt innenfor mixins, som vi tidligere har lagt til støtte. For eksempel kan vi lage en mixin for å generere kolonnekonfigurasjonskoden som:
@ define-mixin kolonner $ count @if $ count == 3 width: 33%; flyte: venstre; @else hvis $ telle == 2 bredde: 50%; flyte: venstre; @else bredde: 100%; .other_column @mixin kolonner 2;
Dette gir deg produksjonen:
.another_column bredde: 50%; flyte: venstre;
Som nevnt tidligere er postcss-advanced-variabler et annet utmerket plugin-alternativ som håndterer variabler, looper og conditionals alt i ett.
I en tidligere opplæring brukte vi postcss-calc, via cssnano, for å bidra til å gjøre forekomster av calc () bruk mer effektivt. I sammenheng med preprocessing kan det imidlertid være veldig nyttig hvor vi kanskje vil bruke matte i stilarkene våre.
Gå videre og installer postcss-calc, så skal vi teste det ut ved å lage kolonnegenerasjonen mixin vi har lagt til ovenfor, mer effektiv.
Akkurat nå bruker vi conditionals for å sjekke om mixin er $ count argumentet er satt til enten 1, 2 eller 3 Deretter utgir du en tilsvarende forhåndsberegnet bredde. I stedet bruker vi calc () For å automatisk utføre riktig bredde for vår kolonnekode, uansett hvilket nummer som passerer gjennom mixin.
Legg til i filen "src / style.css":
@ define-mixin columns_calc $ count width: calc (100% / $ count); @if $ count> 1 float: left; .column_calculated @mixin columns_calc 2;
I stedet for hardkoding av prosentvise bredder vi trenger for visse antall kolonner, beregner vi nå det på fly.
Postcss-calc plugin konverterer bredde: calc (100% / $ telling); inn i en statisk mengde avhengig av verdien som er bestått når vi kaller mixin, i dette tilfellet 2.
Kompil koden din og du bør se denne utgangen:
.kolonne_kalkulert bredde: 50%; flyte: venstre;
Merk: Hvor postcss-calc kan løse calc () til en statisk verdi vil den sende den inn i koden din. Hvis det ikke kan, vil det ikke endre noe, så du kan fortsatt bruke calc () for verdier som må håndteres av nettleseren ved kjøring.
For nesting bruker vi samme plugin som brukes i PreCSS-pakken, slik at du kan se tilbake til forrige veiledning for full informasjon om syntaks.
Installer postcss-nested så test at alt fungerer som det skal ved å kompilere denne koden:
.meny bredde: 100%; en tekst-dekorasjon: ingen;
Din resulterende CSS skal være:
.meny bredde: 100%; .menu en tekst-dekorasjon: ingen;
For utvidelser bruker vi plugin-modulen for postcss-sass-extend. Det vil gi oss forskjellig syntaks til bruk enn det vi dekket i vår tidligere opplæring om å jobbe med PreCSS. Istedenfor å strekke seg blir definert med @ define-extend extend_name ... de er definert med % extend_name ....
De brukes fortsatt med den i det vesentlige samme syntaksen av @extend% extend_name;.
Legg merke til at postcss-sass-extend plugin faktisk leveres med PreCSS, men jeg antar at den ikke lastes som standard som da jeg forsøkte å bruke den nødvendige syntaksen, kompilerte den ikke.
Etter å ha installert postcss-sass-utvide inn i prosjektet, test det ut med følgende kode:
% rounded_button border-radius: 0.5rem; polstring: 1em; grensebredde: 0,0625rem; border-style: solid; .blue_button @extend% rounded_button; border-farge: # 2F74D1; bakgrunnsfarge: # 3B8EFF; .red_button @extend% rounded_button; border-farge: # C41A1E; bakgrunnsfarge: # FF2025;
Det burde kompilere til:
.blue_button, .red_button border-radius: 0.5rem; polstring: 1em; grensebredde: 0,0625rem; border-style: solid; .blue_button border-color: # 2F74D1; bakgrunnsfarge: # 3B8EFF; .red_button border-color: # C41A1E; bakgrunnsfarge: # FF2025;
Så langt har vi dekket hva som kunne betraktes som kjernegenskapene som er felles for de fleste preprosessorer. Imidlertid er det enda flere plugins tilgjengelig for å tilby ekstra funksjoner; Noen av disse funksjonene finnes i andre preprosessorer, og noen må du gå til PostCSS for å finne. Vi vil gå over disse ekstra alternativene kort nå.
Evnen til å finjustere farger kan være en av de mest nyttige funksjonene som finnes i preprosessorer. Det er faktisk flere fargeplugger for PostCSS, men disse er tre som befinner seg spesielt hjemme i et preprocessing-oppsett. De gir mulighet for ulike fargetransformasjoner, inkludert lyn, mørkere, metning, legge til alfaverdier og mer.
Funksjonaliteten som tilbys av dette pluginet, kan sammenlignes med de sømløse miksene av Stylus, der i stedet for å bruke en syntaks som @mixin, du definerer bunker med kode på en slik måte at de senere kan brukes i kode på samme måte som en opprinnelig egenskap, f.eks.
/ * Definer en eiendom * / size: $ size height: $ size; bredde: $ size; / * Bruk den som en opprinnelig egenskap * / .square size: 50px;
Pluggen kan også brukes til å omdefinere innfødte egenskaper for å dekke dine behov.
Eiendomsoppslag er en funksjon som finnes i Stylus som kan være veldig nyttig. Det lar deg slå opp verdien av en eiendom fra samme stil. For eksempel kan du angi en riktig margin for å matche til venstre med: margin-venstre: 20px; margin-høyre: @ margin-left;
Mens den vanlige nestingen vi dekket over uønskede selektorer, stikket pluggen-nestet-props-pluggen unngår nestede egenskaper, for eksempel:
/ * Originalkode * / .element border: width: 1px; stil: solid; farge: #ccc; / * Etter behandling * / .element border-width: 1px; border-style: solid; border-farge: #ccc;
Matchende gir deg en annen måte å utføre betingede kontroller, denne gangen ved å bruke Rust som mønstermatching, noe som ligner på bytte setninger i JavaScript eller PHP. Dette kan gi deg en mer effektiv måte å kontrollere flere forhold enn å skrive mange @if annet sjekker.
CSS sprite generasjon, en populær funksjon i Compass, kan også gjøres via plug-in-plug-in. Plugin vil skanne CSS for bilder, kombinere bildene i et sprite-ark, og oppdatere koden etter behov for å vise det nye spritarket riktig.
Det er for øyeblikket en veldig robust liste over språkforlengelsesprogrammer å velge mellom, mer enn vi kan dekke her, så sjekk ut hele listen på: https://github.com/postcss/postcss#language-extensions
For mange mennesker er evnen til å skrive i tersk, effektiv syntaks (typisk sans semikolon og krøllete braces) en av de store appellene til preprosessorer som Stylus eller Sass. Den nylig utgitte versjonen 5.0 av PostCSS støtter nå tilpassede parsere som gjør at nye syntakser kan støttes. SugarSS skal være den terse syntakseparseren, og diskusjoner er for tiden åpne for hvordan denne syntaksen skal struktureres.
PostCSS er fortsatt relativt nytt, og du kan finne at det er noe du vil oppnå med din egendefinerte preprosessor, for hvilken det for øyeblikket ikke er noen plugin. Skjønnheten i dette modulære økosystemet er at du har muligheten til å løse dette problemet selv ved å lage ditt eget plugin. Alle kan gjøre det, og barrieren for oppføring er langt lavere enn du skulle prøve å legge til din egen funksjonalitet til Stylus, Sass eller LESS. Vi lærer hvordan i en senere opplæring.
Du trenger ikke å velge mellom PreCSS og rulle din egen preprocessor hvis du vil bruke PostCSS. Du kan faktisk velge bort hvilken som helst PostCSS-basert forbehandling helt, hvis du velger, istedenfor å bruke den ved siden av din favoritt preprosessor.
I neste veiledning lærer vi hvordan du bruker PostCSS i forbindelse med Stylus, Sass eller LESS. Ser deg der!
