Share
Ikke så lenge siden så vi på Grunnleggende om LESS, og selv om dette er en solid referanse for nybegynnere, er det mye mer du kan gjøre med MINDRE! Målet med denne opplæringen er å utvide kunnskapen fra forrige artikkel og gi deg noen praktiske tips om hvordan du kan utnytte alle de gode tingene med mindre.
Konseptene i den forrige artikkelen vil være avgjørende for å unngå denne. Variabler, mixins, funksjoner og hekker i MINDRE bør alle være kjent, og du bør ha minst noen hender på kunnskap om MINDRE.
Merk: Det er en hel del subjektive råd i denne artikkelen. Mange ting vi skal diskutere, har å gjøre med metodikk i motsetning til regler og regler i et språk. Jeg vil vise deg hvordan jeg organiserer filer og lager mixins, men det kan være andre, bedre måter å gjøre ting på. Hvis du tror du bruker en bedre struktur, eller du har noen tips og triks, kan du ikke løses i kommentarene.
Organisering av filene dine er alltid ekstremt viktig, veldig mye så for mindre også. Jeg lager vanligvis en "stiler" -mappe i hovedprosjektkatalogen der jeg lagrer alle stilene som kreves for dette prosjektet. Så hva skjer hvis prosjektet krever at du inkluderer css-filer fra flere steder?
Den beste måten å gjøre livet ditt enkelt på er å bruke et verktøy som Winless eller CodeKit. Disse verktøyene lar deg kompilere forskjellige filer til forskjellige steder. Dette gjør at du kan beholde alle stilfilene dine på ett sted, mens du faktisk samler dem til forskjellige mapper over prosjektene dine.
Som du kan se, i dette WordPress-prosjektet er den uthevede "style.less" -filen inneholdt i mappen 'stiler'. Siden WordPress krever en 'style.css' -fil i hovedkatalogen, må vi kompilere den der. CodeKit eller et lignende verktøy gjør det enkelt, siden du bare trenger å sette det opp en gang, så kan du glemme det til slutten av prosjektet.
Et annet problem som kan oppstå med CSS-filer, er hvordan du håndterer tredjepartsfiler. Rutenettsystemer, stiler for JavaScript-glidere, tilbakestiller og mer krever bruk av (noen ganger flere) CSS-filer. Det er vanligvis to metoder for å gjøre dette skje. Du kobler enten filene til websiden din separat, eller du plasserer all koden i en fil og minimerer den for ytelsesformål. Med et MINDRE kompilatorverktøy blir dette lettere igjen!
Ved å bruke importeringsregler kan du trekke alle filene inn i det viktigste LESS stilarket. Du kan også importere færre filer, gjøre regler, mixins og andre elementer som kan brukes i alle etterfølgende filer.
Merk: Mens denne metoden er nyttig, er det ikke en universell løsning. I noen tilfeller må du kanskje inkludere alle filer separat, i andre kan det best å inkludere alt i en fil.
Det største problemet med CSS er den ekstreme mangelen på konsistens i nesten alle prosjekter. Denne situasjonen stammer hovedsakelig fra selve språket, ikke nødvendigvis fra programmørens inepthet. CSS er et veldig løs og tilgivende språk som betyr at det fremmer konfigurasjon over konvensjonen, mens den andre veien ville være å foretrekke. I tillegg pleier CSS å bli kodet enda mer prosedyrisk enn vanlig, noe som betyr at globale mønstre ikke alltid blir lagt merke til og implementert så enkelt som de kunne være.
Mens LESS ikke er en cureall, gjør det deg i stand til å være mye mer konsistent ved å gi deg verktøy som funksjoner og nesting. La oss ta en titt på noen få eksempler hvor du kan oppnå bedre konsistens med MINDRE verktøy.
.radius (@radius: 5px) -webkit-border-radius (@radius); -khtml-grense-radius (@radius); -moz-grense-radius (@radius); -grense-radius (@radius); -grense-radius (@radius); grense-radius (@radius);
Uten MIND, trenger du å kopiere lim inn disse reglene når det er nødvendig. Mange skriver bare når de går, så det er mye mer sannsynlig at du vil glemme et av prefiksetene, eller skrive dem i en annen rekkefølge. Selv om disse ikke vil være dealbreakers for nettstedet ditt, tilføyer hver liten inkonsekvens unødvendig støy til koden din.
Den nestable karakteren av regler gir deg også mulighet til å legge til ordre i koden din. Jeg prøver å bruke så få divs og andre beholderelementer som mulig, og jeg prøver å målrette hvert element så spesifikt som mulig
.kommentarliste .comment .comment-date .comment-time color: # 888;
Dette virker litt overflødig i begynnelsen, og jeg er enig, i en viss forstand er det. Men det gjør alt helt klart.
Nyttigheten av dette vil bare være tydelig hvis du bruker det i et større prosjekt, men her er en rask utdrag som viser hvordan en kommentar blir gjort responsiv. Under en bestemt bredde er tidsdelen av kommentardagen skjult for å spare plass.
@media-skjerm og (maksimal bredde: 600px) .commentlist .comment-container .comment-main .comment-header .comment-date .time display: none;
Jeg er enig i at dette ser forferdelig ut. Men ingen tenkning gikk inn i å skape regelen. Ingen tenkning betyr lett backtracking fordi du ikke trenger å finne ut smart tricks du har lagt til underveis. Du kan også fortelle hva denne regelen gjør bare ved å se på den.
Mitt siste argument for konsistens er en mer komplisert, men jeg synes det er verdt å se på. Jeg bygger WordPress-temaer til salgs på ThemeForest, og en funksjon er at du kan velge hvilken som helst farge for temaet ditt. Elementer er recolored etter eget valg. Måten dette er gjort er at når som helst en "primærfarge" er definert, overskrives den med dynamisk CSS-kode vi sender ut med PHP. Dette ser noe ut som dette:
Innholdet i vår MINDRE fil:
@ farge-primær: rød; .button bakgrunn: @ farge-primær; polstring: 8px 20px;
Innhold av PHP inkludert i slutten av HTML-overskriften:
I utgangspunktet, når det er en referanse til '@ color-primary' i LESS-filen, må vi opprette en PHP-regel for å sikre at fargene valgt av brukeren blir reflektert på nettstedet. Dette kan ta en stund og enda viktigere er ekstremt kjedelig. For å bekjempe kjedsomheten oppretter vi et skript som analyserer vår MINDRE fil og lager PHP-koden som vi bare kan kopiere og lime på en gang. Dette er litt diffult fordi det er noen dynamiske regler med funksjoner og hva som ikke, men for å trekke dette av, må vår MINDRE fil være godt strukturert og konsekvent.
En god timesaver og en måte å øke konsistensen på tvers av prosjekter, er å bruke et felles regelbibliotek. Tidligere spurte jeg; hvorfor skrive ut alle grensestrålereglene når vi kan bruke en mixin? Nå kan vi hoppe et nivå høyere. Hvorfor omskrive rammen radius mixin for hvert prosjekt når du bare kan bruke den samme?
Det er noen mixins (spesielt de som takler leverandørspesifikasjoner) som vil være de samme på tvers av alle prosjekter. Disse kan skilles ut i en "mixins.less" -fil som du kan bruke hvor som helst du vil. Her er noen eksempler på mixins som alltid er nyttige å ha rundt.
.opacity (@opacity: 0.8) @ieopacity: @opacity * 100; filter: ~ "alfa (opacity = @ ieopacity)"; -Khtml-opacity: @opacity; -moz-opacity: @opacity; opacity: @opacity;
.gradient (@start, @end) bakgrunn: @start; filter: ~ "progid: DXImageTransform.Microsoft.gradient (startColorstr =" @ start ", endColorstr =" @ end ", GradientType = 0)"; bakgrunn: -webkit-gradient (lineær, venstre topp, venstre bunn, fargestopp (0%, @ start), fargestopp (100%, @ ende)); bakgrunn: -webkit-lineær-gradient (topp, @start 0%, @end 100%); bakgrunn: -moz-lineær-gradient (topp, @start 0%, @end 100%); bakgrunn: -ms-lineær-gradient (topp, @start 0%, @end 100%); bakgrunn: -o-lineær-gradient (topp, @start 0%, @end 100%); bakgrunn: lineær gradient (topp, @start 0%, @end 100%);
.elementfarge (@color) når (lyshet (@color)> = 60%) farge: @color - # 888; .element-farge (@color) når (lyshet (@color) < 60% ) color: #fff;
Denne siste er spesielt kult. Hvis bakgrunnsfargen er lys, vil tekstfargen være en veldig mørk versjon av samme farge.
Jeg foreslår alltid å tenke på plasseringen av regelen du skriver. Er du sikker på at den brukes globalt for alle prosjekter? Det kan være fristende å sette en hel del regler der inne, men i virkeligheten kan det være bedre å lage en prosjektspesifikk fil også.
Husk bildet av kommentaren tidligere? Beholderen til det elementet har et bestemt format. Den har en hvit kant og en grå kontur. Mange andre elementer på tvers av dette temaet deler dette mønsteret. Dette kan opprettes med en regel som sådan:
.boks grense: 1px solid #fff; disposisjon: 1px solid #dedede; .komment .box; bakgrunn: #eeeeee;
Mens dette er brukt over alt her, vil det ikke være det samme på tvers av flere prosjekter. Derfor er det bedre å lage en fil som "mytheme.less" som inneholder disse mye brukte, men temaspesifikke reglene. Hvis du virkelig vil bruke noe som i den globale filen, kan du utvide på det slik:
.box-bordered (@ border-color: #fff, @ outline-color: #dedede) border: 1px solid @ border-color; disposisjon: 1px solid @ konturfarge;
Denne regelen vil tillate deg å lage samme boksestil like enkelt, men du kan også legge til parametere for å lage forskjellige fargete boksgrenser. Du kan ta dette et skritt videre ved å abstrahere ting enda mer og lage en "bootstrap.less" -fil; Dette bringer oss pent inn i vårt neste emne, og skaper et rammeverk for oss selv.
@ border-box-border-farge: #fff; @ border-box-outline-farge: #dedede;
.boks-grenser (@bc: @ border-box-border-farge, @oc: @ border-box-outline-farge) border: 1px solid @bc; omriss: 1px solid @oc;
Å lage ditt eget rammeverk er vanligvis et nei-nei, med mindre du er veldig avansert i ditt hovedfelt (og 5-6 andre), og du har veldig god grunn til det. Med CSS og mindre er det litt annerledes; Du kan begynne å lage din egen ramme fra dag ett. Siden LESS er en superset av CSS noe du passer fint inn i eksisterende kode. Siden CSS er tilgivende og cascading, kan du ikke gjøre noen permanent skade som ikke kan fortrykkes.
Jeg foreslår at du lager en hovedmixins-fil til å begynne med. Du kan alltid fjerne ting fra det eller legge til det etter behov. Senere kan du legge til prosjektspesifikke filer, tredjepartsfiler, en bootstrap-fil og så videre. Her er hvordan rammeverket mitt er organisert.
Som med hvilket språk som helst, inneholder praktiske kodene mange forskjellige utfordringer og teknikker som ikke kan oppdages og overvinnes ved bare å se på dokumentasjonen. For å bruke MINDRE i sin helhet bør du lese forslag og prøve å ta i logikken, men til slutt må du få erfaring. Konsistens, logikk og enkelhet bør være dine veiledende ord og LESS gir deg alle verktøyene for å oppnå dette.
Til slutt vil jeg ønske deg velkommen innspillingen, og jeg vil gjerne høre hvordan du organiserer MINDRE og hvordan du implementerer den i prosjektene dine. Takk for at du leste!
Accentsconagua