Lühiülevaade LESSi ja SASSi erinevustest. Olulised erinevused Sassi ja SCSS-i vahel

Mulle meeldib SASS-i süntaks selle lühiduse tõttu rohkem kui SCSS. Kuid stiilide massiline pesastumine SASS-is võib selle lühiduse eelised kiiresti kõrvaldada. Igal juhul pole SASS-i ja SCSS-i erinevus põhimõtteline. LESS osutus SCSS-ile lähedasemaks kui SASS-ile. Ja üldiselt on see sama asi. Erinevusi pole palju, kuid paar neist muudavad jõudude vahekorda põhimõtteliselt.

1. VÄHEM – saab kliendipoolset kasutada JS-i.

Täpsemalt, asi pole selles, et ta suudab, ta on selleks loodud. Levinud tava LESS-koodi kasutamiseks:

Siis lisati sellele ka serveris kompileerimise võimalus (nii js kui ka ruby).

Esmapilgul tundub see kummaline vara. Milleks kompileerida kliendi poolel, kui saab suurepäraselt kompileerida serveris ja serveerida valmis kokkusurutud CSS-i, nagu me SASSiga oleme harjunud?

Põhjus selgub pärast LESS-i dokumentatsiooni mittekirjeldavate viimaste ridade uurimist:

@height: `document.body.clientHeight`;

Selline väike üksildane joon annab võimalusi, millest küljendajad on stiilide valdamise algusest saati vaid unistanud. Kliendipoolse Java-skripti kutsumine CSS-ist ja brauseri tegelike sätete arvestamine stiilide loomisel.

See tähendab, et meil on nüüd võimalus esmalt laadida DOM ja seejärel see selle jaoks luua kohandatud CSS otse kliendi poolel. Seejärel mõelge ise, milliseid võimalusi see avab.

Kas teie projekt seda vajab, on hoopis teine ​​küsimus. Selge on see, et kõik on harjunud kliendi ebakindluse/sõltumatuse ja paigutusega stiilis “teeme universaalselt nii, et seda näidatakse enam-vähem kõigile kõikidel resolutsioonidel”. Aga see ei ole põhjus unustada, et nüüd on selline võimalus olemas ja sellega saab teha näiteks väga paindliku küljenduse.

2. LESS-il, erinevalt SASS/SCSS-ist, puudub loogika.

LESS-is ei ole kui/siis, eest jne. Kuigi, arvestades, et JS on sellesse hõlpsasti sisse ehitatud, arvan, et loogikat on täiesti võimalik kruvida. Ma pole seda proovinud.

3. Segamine on lihtsam VÄHEM + saab segada klasse.

Mulle väga meeldis, et LESS-is saab definitsiooni kaasata ka teiste klasside omadusi. Klass ise on mixin. See on veel üks funktsioon, mida SASS-il/SCSS-il pole. Saate lisada lahtrisse LESS tavalise CSS-faili ja kasutada selle klasse oma atribuutide määratlemiseks. Näiteks:

Mähi (
text-wrap: wrap;
white-space: pre-wrap;
tühik: -moz-pre-wrap;
sõnamurdmine: murdsõna;
}
pre ( .wrap )

Kokkuvõte

Kui 1. punkt välja arvata, pole vahe suur ja valik on harrastaja jaoks suurem.

Minu jaoks isiklikult tundub LESS oma lihtsuse tõttu atraktiivsem. Ma pole kunagi varem stiilides tsükleid ja tingimusi vajanud. Klassikalised utiliidid, nagu "kast-vari, lineaarne gradient, tume", on saadaval VÄHEM.

Jah, SASS-i jaoks on juba kirjutatud palju valmis teeke (

Autorilt: Esiteks, mis on eelprotsessor? Lühidalt öeldes on eeltöötlusprogramm programm, mis muudab andmeid, et need vastaksid teise programmi sisendnõuetele. CSS-i eelprotsessorid on skriptikeel, mis laiendab tavalise CSS-i võimalusi muutujate, pesastusreeglite, funktsioonide ja loogiliste plokkide abil.

Miks ma peaksin seda kasutama?

Sageli leiad end olukorrast, kus pead kasutama sama väärtus konkreetse kinnisvara jaoks erinevad kohad. Näiteks määrasite esmalt saidi põhivärviks punase. Seejärel peate selle roheliseks muutma.

Muutujate puhul ei pea te otsima ja asendama iga punase värvi mainimist stiilides. Määrate muutuja väärtuse üks kord, näiteks "põhivärv", ja seejärel kasutate seda muutujat väärtusena.

Põhivärvi väärtus muutub ühes kohas. CSS-faile saate importida ka muudest allikatest, muretsemata võrgupäringute arvu pärast, kuna need saab kõik enne kompileerimist üheks failiks ühendada.

Tänu CSS-i eelprotsessorite pesastatud olemusele saate kompaktse koodi sama tulemusega. LESS ja SCSS põhinevad DRY põhimõttel, mis tähendab "ära korda ennast" või "ära korda ennast".

Eeltöötlejad. Kiire algus

Mis VÄHEMAL viga on?

Võrk on juba täis arutelusid selle üle, kumb on parem: LESS või SCSS. Seetõttu ma mõlemat teemat üksikasjalikumalt ei käsitle. Selle asemel räägin väikestest probleemidest, mis mul oli VÄHEM.

SCSS kasutab muutujate määratlemiseks sümbolit $, samas kui LESS kasutab sümbolit @. Kuna CSS kasutab meediumipäringute, impordi ja võtmekaadri animatsioonide jaoks ka sümbolit @, võib see arendajatele segadusse ajada.

$ sümbolit CSS-is ei kasutata. Sümbol @ on SCSS-is olemas, kuid seda kasutatakse @if , @else , @each , @for ja @while direktiivide jaoks.

Kuigi see stsenaarium ei ole kõigi jaoks realistlik, on parem kasutada elementide eraldamiseks erinevaid ID-sid.

SCSS toetab traditsioonilist loogilisi väljendeid nagu if/else, plokid ja silmused. LESS-iga kaitstud mixinid on silmale kergemad, kuid raskemini mõistetavad.

Saab teha VÄHEM...

...või lihtsalt SCSS-i kasutades.

LESS määratleb ainult ühe valvega segu. Seetõttu ei saa te lihtsalt teist argumenti edastada ja seda samas mixinis töödelda, dubleerides kõigi jaoks koodi võimalikud stsenaariumid. Tegelikult on LESS (vähem) rohkem (sõnamäng).

Ma tean, et koodi on võimalik lühendada, kasutades sel juhul atribuutide nimedena liitväärtusi, kuid probleem on selles, et ma ei saa tinglikult vastendada sama miksini kahte erinevat osa VÄHEM.

Selle koodiga on rohkem peavalusid...

Eeltöötlejad. Kiire algus

Õppige töötamise põhitõdesid Vähem eeltöötlejaid ja Sass koos täielik null vähem kui 2 nädala jooksul

...kui sellega.

Sama tulemuse saavutamiseks LESS-iga pidin kõik eelnevalt defineerima, kirjutama mixini, saama indeksi positsiooni, kordama seda oma loogikaga, kuni indeksi väärtus on võrdne nulliga ja kutsuge mikser käsitsi.

Kuigi see on minu isiklik arvamus, arvan, et SCSS käsitleb arvutusväärtusi ja matemaatilisi väärtusi üldiselt paremini.

Mis sellel viga on?

VÄHEM seevastu on palju keerulisem. Näiteks kui ma seda kasutan, siis ma ei püüa arvutusi teha. Aga isegi kui ma seda teeksin, siis mis ajast võrdub 100% miinus 50 pikslit 50%?

VÄHEM, miks te eirate väärtusi muutuste ühikutega?

Miks sa paned mind kargud õppima, kui ma juba CSS-i oskan?

Ja viimane asi. Tänu LibSassi projektile on SCSS-il palju ümbriseid teiste keelte jaoks, nagu C, Go, PHP, Python, Dart jne.

Miks otsustasime LESSist loobuda SCSS-i kasuks?

JotForm-kaartide väljatöötamise ajal pidime muutuvate väärtuste eeltöödelda – eelkompileerimine ja serveripoolne vahemällu salvestamine samal ajal; ja seda kõike tuli teha suurepäraselt.

Tahtsime, et kasutajad saaksid kohandada välimus vormid Nii et kõik muudatused kuvatakse kohe ja samaaegselt ning salvestatakse serverisse vahemällu. Oma kasutajate huvides ei tahtnud me käitada VÄHEM kliendikestat, sest see eeldaks arvutusvõimsus klient – ​​ja paljud asjad võivad valesti minna.

Me ei alustanud arendustsüklit eesmärgiga liikuda LESS-ilt SCSS-ile. Kuid nende pisiprobleemidega tegelemise poole peal oli LESSi jaoks korraliku ümbrise puudumine viimane piisk karikasse.

Kuid erinevused LESS-i ja SCSS-i vahel on vähem olulised kui see, mis neil on ühine. Lõppkokkuvõttes pole vahet, millist eelprotsessorit kasutate, kui seda kasutate.

Üritab hallata tohutut projekti ühe CSS-faili ja traditsioonilise CSS-i struktuur palju keerulisem kui paari probleemiga eelprotsessori kasutamine.

Mulle meeldib SASS-i süntaks selle lühiduse tõttu rohkem kui SCSS. Kuid stiilide massiline pesastumine SASS-is võib selle lühiduse eelised kiiresti kõrvaldada. Igal juhul pole SASS-i ja SCSS-i erinevus põhimõtteline. LESS osutus SCSS-ile lähedasemaks kui SASS-ile. Ja üldiselt on see sama asi. Erinevusi pole palju, kuid paar neist muudavad jõudude vahekorda põhimõtteliselt.

1. VÄHEM – saab kliendipoolset kasutada JS-i.

Täpsemalt, asi pole selles, et ta suudab, ta on selleks loodud. Levinud tava LESS-koodi kasutamiseks:

Siis lisati sellele ka serveris kompileerimise võimalus (nii js kui ka ruby).

Esmapilgul tundub see kummaline vara. Milleks kompileerida kliendi poolel, kui saab suurepäraselt kompileerida serveris ja serveerida valmis kokkusurutud CSS-i, nagu me SASSiga oleme harjunud?

Põhjus selgub pärast LESS-i dokumentatsiooni mittekirjeldavate viimaste ridade uurimist:

@height: `document.body.clientHeight`;

Selline väike üksildane joon annab võimalusi, millest küljendajad on stiilide valdamise algusest saati vaid unistanud. Kliendipoolse Java-skripti kutsumine CSS-ist ja brauseri tegelike sätete arvestamine stiilide loomisel.

See tähendab, et meil on nüüd võimalus esmalt laadida DOM ja seejärel luua selle jaoks spetsiaalne CSS otse kliendi poolel. Seejärel mõelge ise, milliseid võimalusi see avab.

Kas teie projekt seda vajab, on hoopis teine ​​küsimus. Selge on see, et kõik on harjunud kliendi ebakindluse/sõltumatuse ja paigutusega stiilis “teeme universaalselt nii, et seda näidatakse enam-vähem kõigile kõikidel resolutsioonidel”. Aga see ei ole põhjus unustada, et nüüd on selline võimalus olemas ja sellega saab teha näiteks väga paindliku küljenduse.

2. LESS-il, erinevalt SASS/SCSS-ist, puudub loogika.

LESS-is ei ole kui/siis, eest jne. Kuigi, arvestades, et JS on sellesse hõlpsasti sisse ehitatud, arvan, et loogikat on täiesti võimalik kruvida. Ma pole seda proovinud.

3. Segamine on lihtsam VÄHEM + saab segada klasse.

Mulle väga meeldis, et LESS-is saab definitsiooni kaasata ka teiste klasside omadusi. Klass ise on mixin. See on veel üks funktsioon, mida SASS-il/SCSS-il pole. Saate lisada lahtrisse LESS tavalise CSS-faili ja kasutada selle klasse oma atribuutide määratlemiseks. Näiteks:

Mähi (
text-wrap: wrap;
white-space: pre-wrap;
tühik: -moz-pre-wrap;
sõnamurdmine: murdsõna;
}
pre ( .wrap )

Kokkuvõte

Kui 1. punkt välja arvata, pole vahe suur ja valik on harrastaja jaoks suurem.

Minu jaoks isiklikult tundub LESS oma lihtsuse tõttu atraktiivsem. Ma pole kunagi varem stiilides tsükleid ja tingimusi vajanud. Klassikalised utiliidid, nagu "kast-vari, lineaarne gradient, tume", on saadaval VÄHEM.

Jah, SASS-i jaoks on juba kirjutatud palju valmis teeke (

Kirjutasin palju sisse Hiljuti Sassi kohta, kuid mõnest hiljutisest kommentaarist sain aru, et kõigil pole selget ettekujutust, mis Sass on. Teeme natuke selgemaks:

Sassist rääkides peame tavaliselt silmas eeltöötlejat ja keelt tervikuna. Ütleme näiteks "me kasutame Sassi" või "siin on Sassi mixin".

Samal ajal lubab Sass (eelprotsessor) kahte erinevat süntaksit:

  • Sass, tuntud ka kui taandega süntaks;
  • SCSS, CSS-i sarnane süntaks.
Lugu

Sass oli algselt osa teisest eeltöötlejast Hamlist, mille leiutasid ja kirjutasid Ruby arendajad.

Seega kasutasid Sassi stiilid rubiinitaolist süntaksit, ilma sulgudeta, semikooloniteta ja rangete taandeta, näiteks järgmiselt:

// Muutuja!primary-color= hotpink // Mixin =border-radius(!radius) -webkit-border-radius= !radius -moz-border-radius= !radius border-radius= !radius .my-element color= !primary-color width= 100% overflow= peidetud .my-other-element +border-radius(5px)

Nagu näete, on erinevus tavalise CSS-iga võrreldes märgatav! Isegi kui olete Sassi (eeltöötleja) kasutaja, näete, et see on väga erinev sellest, millega oleme harjunud.

Muutujat tähistatakse ! , mitte $ , väärtuse määramise sümbol = , mitte : . Üsna ebatavaline.

Kuid selline nägi Sass välja enne 2010. aasta mais välja antud versiooni 3.0, mis võeti täielikult kasutusele uus süntaks nimega SCSS või Sassy CSS.

Tema eesmärk oli tuua Sassi süntaks CSS-ile lähemale, muutes selle CSS-iga paremini ühilduvaks:

// Muutuja $primary-color: hotpink; // Mixin @mixin border-radius($radius) ( -webkit-border-radius: $radius; -moz-border-radius: $radius; border-radius: $radius; ) .my-element ( värv: $primary -värv: 100% ülevool: peidetud .my-other-element ( @include border-radius(5px); )

SCSS on kindlasti CSS-ile lähemal kui Sass. Sassi arendajad tegid kõvasti tööd, et muuta mõlemad süntaksid üksteisele lähedasemaks, asendades ! (muutuv märk) ja = (määramismärk) $ ja: CSS-ist.

Seega võite uut projekti alustades mõelda, millist süntaksit kasutada. Lubage mul seda teemat käsitleda ja selgitada iga süntaksi plusse ja miinuseid.

Sassi taandega süntaksi plussid

Kuigi see süntaks võib teile tunduda pisut kummaline, on sellel mitu huvitavaid hetki. Esiteks on see lühem ja lihtsam tippida. Sulgusid ega semikooloneid pole, neid pole vaja.

Veel parem! See ei vaja @mixin või @include, kui sellest piisab lihtne sümbol: = ja + .

Samuti pakub Sassi süntaks taande kasutamise tõttu puhtaid kodeerimisstandardeid. Kuna vale taane võib rikkuda kogu .sass-laaditabeli, on esimene samm siin tagada, et kood on puhas ja õigesti vormindatud.

Sassi koodi kirjutamiseks on ainult üks viis: kirjutage see õigesti.

Aga ole ettevaatlik! Treppimisel on Sassis tõeväärtus. Kui valijaploki taane on rakendatud, tähendab see, et see on pesastatud valija.

Näiteks:

Element-a värv: hotpink .element-b float: left ... väljastab järgmise CSS-koodi: .element-a ( color: hotpink; ) .element-a .element-b ( float: left; )

Lihtne fakt .element-b nihutamine ühe taseme võrra paremale tähendab, et see on nii laps element alates .element-a , mis muudab saadud CSS-koodi. Seega olge süvenditega ettevaatlik!

Autsaiderina arvan, et taandel põhinev süntaks meeldiks ilmselt rohkem meeskonnale, kes töötab peamiselt Ruby/Pythoniga, kui PHP/Java programmeerijate meeskonnale (kuigi mulle meeldiks kuulda vastupidiseid arvamusi).

SCSS-i süntaksi plussid

Alustuseks on see täielikult CSS-iga ühilduv. See tähendab, et saate ümber nimetada CSS-fail failis .scss ja see töötab nii, nagu poleks midagi juhtunud.

SCSS-i CSS-iga täielikult ühilduvaks muutmine on Sassi toe jaoks alati olnud prioriteet alates SCSS-i väljaandmisest ja minu arvates on see tugev külg.

Samuti püüavad nad silma peal hoida sellel, mis võib tulevikus muutuda kehtivaks CSS-i süntaksiks, ja seda rakendada (seega @direktiivid ).

Kuna SCSS ühildub CSS-iga, ei vaja see praktiliselt mingit lisakoolitust. Süntaks on üsna sama: lõppude lõpuks on see lihtsalt CSS koos mõningate lisadega.

See on uutele arendajatele oluline, et nad saaksid kiiresti kodeerimist alustada, Sassist palju teadmata.

See on ka loetavam, kuna konkreetsed konstruktsioonid on juba mõistlikud. Kui näete @mixin , teate, et see on mixin deklaratsioon; kui näete @include , teate, et see on segakõne.

Mingeid nööre pole ja kõik on mõtet ilma tõlgendamiseta.

Samuti on peaaegu kõik Sassi olemasolevad tööriistad, pistikprogrammid ja demod välja töötatud SCSS-i süntaksi abil. See süntaks on üha enam orienteeritud professionaalidele ja on nende poolt vaikimisi valitud (kui see pole ainuvõimalik).

Peamiselt ülaltoodud põhjustel. Näiteks on üha raskem leida esiletõstmist puhta Sassi taandega süntaksi jaoks; üldiselt on saadaval ainult SCSS-taustvalgustuse valikud.

Järeldus

Valik on igal juhul teie, kuid kui teil pole tõesti mõjuvat põhjust taandega süntaksi kasutamiseks, soovitan tungivalt kasutada SCSS-i Sassi asemel. See pole mitte ainult lihtsam, vaid ka mugavam.

Proovisin korra taande süntaksit ja see meeldis. Eriti selle lühidus ja lihtsus. Kavatsesin kogu oma töökoodi Sassi teisaldada, kuid viimasel hetkel mõtlesin ümber.

Mul on hea meel, et ma seda sammu ei teinud, sest mul oleks nüüd väga raske mõne tööriistaga töötada, kui kasutaksin taandega süntaksit.

Samuti pange tähele, et Sassile ei viidata kunagi täistähtedega akronüümiga, olgu see siis süntaks või programmeerimiskeel. Kuigi SCSS on alati tähistatud suurte tähtedega. Kas soovite teada, miks? Tutvuge saidiga SassnotSASS.com!

Artikli “Mis vahe on Sassil ja SCSS-il” tõlke koostas sõbralik projektimeeskond

Kuni mul oli paar kuud tagasi huvitav olukord. CSS pole minu jaoks kunagi probleemiks olnud (kuigi selles pole üldse midagi keerulist), kuid mind inspireeris idee kasutada muutujaid, et luua mallide ja veebisaitide jaoks midagi nagu värvivalija read. Fikseeritud arvu valikutega palett aitab vältida värvide segunemist ja valitud stiilist eristumist.

Kuidas sa tead, milleks LESSi kasutada ja milleks Sassi? Põhimõtteliselt on nad üksteisega üsna sarnased. Vaatame neid Üldised omadused:

* Mixins – tunnid klassidele.
* Parameetrilised miksinid – klassid, millele saab rakendada funktsioonitüübi parameetreid.
* Pesastatud reeglid – klassid klassides, mis katkestavad korduva koodi.
* Tehted – matemaatika CSS-is.
* Värvifunktsioonid – värvide redigeerimine.
* Nimeruumid – stiilide rühmad, mida saab linkide kaudu kutsuda.
* Ulatus – töö kohalikud muutused stiilides.
* javascripti hindamine – CSS-is määratletud javascripti avaldised.

Peamine erinevus LESSi ja Sassi vahel on nende valmistamise viis. VÄHEM – sisse javascripti raamatukogu ja vastavalt sellele teeb tööd kliendi poolel.

Sass omakorda juhib Rubyt ja jookseb edasi serveri pool. Paljud arendajad ei kasuta VÄHEM, kuna JavaScripti mootoril kulub koodi töötlemiseks kauem aega, mille tulemusel muudetakse brauseri CSS-i. Toimimisviise on mitu. Kasutan seda siis, kui LESS-i kasutatakse ainult arendusprotsessi käigus. Kui olen valmis, kopeerin ja kleebin VÄHEM saadud tulemuse koodi reduktorisse ja seejärel sisse eraldi CSS-fail, mis tuleks lisada VÄHEM failide asemel. Teine võimalus on kasutada failide kompileerimiseks ja minimeerimiseks LESS-i. Mõlemad meetodid vähendavad teie stiilide polsterdamist ja aitavad vältida probleeme, mis võivad tekkida, kui kliendi brauser ei toeta JavaScripti. Seda juhtub harva, kuid seda võimalust ei saa välistada.

Palun kaaluge ka seda Adam Stacoviaki arvustust, mis on kirjutatud pärast seda, kui Smashing Magazine'i artikkel oli Twitteris tihedalt arutletud: „Tegelikult nõuab Sass Rubyt, kuigi seda pole vaja serveris CSS-dokumendiks kompileerida. Seda saab kompileerida kohapeal (nagu on öeldud jaotises LESS) ja seda kompileeritud faili saab teisaldada koos teie projekti, WordPressi malli, Expression Engine'i ja nii edasi. Kuna see on Smashing Magazine ja kasutajaskond on väga erinev, arvan, et paljud teist kasutavad Maci. Seega on Ruby kõigi jaoks vaikeseade Maci masinad, Nii lihtne paigaldus Sass võimaldab teil kohe alustada.

Kui olete Sassi installinud, saate selle kohapeal CSS-iks teisendada ja koodi oma projektiga saata, nagu ma juba kirjeldasin. Kui te pole kindel, kuidas Sassi (või Compassi) kasutamist alustada, oleme sellest piisavalt kirjutanud üksikasjalik juhend nimega " "(Sassi või Compassi kasutamise alustamine)". Täname kõik koos Adamit!

Vähem rohkem!

Paigaldamine

LESS-i on üsna lihtne rakendada igas projektis, mille kallal töötate:

Muutujad

Kui olete arendaja, on muutujad tõenäoliselt teie parimad sõbrad. Kui teil on vaja sama teavet (nt värvi) mitu korda kasutada, on muutuja määramisel tohutu erinevus. Nii garanteerite endale dokumendi sidususe ja vabastate end pidevast dokumendi kerimisest soovitud kuueteistkümnendväärtuse otsimisel, et see kopeerida ja uues elemendis kasutada. Võite isegi lõbutseda kuueteistkümnendväärtuste lisamisega või välistamisega, mida peate genereerima. Võtame selle näite:

@sinine: #00c;
@light_blue: @sinine + #333;
@tume_sinine: @sinine - #333;
Kui rakendame need stiilid kolmele divile, saame gradatsiooniefekti, mis luuakse väärtuste lisamisel ja lahutamisel loomulikust sinisest ja sellest:


Üleminek @light_blue-lt @sinisele @dark_blue-le.

Ainus erinevus LESS ja Sass muutujate vahel on see, et LESS kasutab "@" ja Sass kasutab "$". On ka teisi erinevusi, kuid neid pole nii raske õppida.

Segud

Võimalusel saame luua stiili, mis on mõeldud taaskasutamiseks samas laaditabeli dokumendis. Keegi ei keela teil kasutada mitut klassi, rakendada neid HTML-i elementidele, kuid saate seda teha ka sulgemata CSS dokument. Peate lihtsalt VÄHEM kasutama. Selle demonstreerimiseks olen lisanud koodi, mis võimaldab teil lehel kahte elementi stiilida.

Piir (
border-top: 1px punktiir #333;
}

article.post(
taust: #eee;
.piir;
}

ul.menüü (
taust: #ccc;
.piir;
}
Lõppkokkuvõttes saate midagi sarnast sellele, mida lootsite saada, minnes tagasi oma HTML-dokumendi juurde ja lisades mõlemale elemendile klassi ".bordered". Kuid oluline on märkida, et rakendasite selle ilma CSS-i dokumenti sulgemata. See toimib järgmiselt:


Nii artiklitel kui ka järjestamata loendil on ääriste stiil.

Sassiga kuulutate "@mixin" stiiliprioriteediks, et määratleda see mixinina. Järgmisena deklareerite selle kutsumiseks "@include".

@mixin border (
border-top: 1px punktiir #333;
}

article.post(
taust: #eee;
@include border;
}

ul.menüü (
taust: #ccc;
@include border;
}
Parameetrilised segud

Sarnaselt sellele, kuidas te CSS-is funktsioone kasutate, seda funktsiooni võib olla eriti kasulik neile, kes soovivad näiliselt kasutada piiramatud võimalused kaasaegne CSS. Parim ja kasulikum näide selle kasutamisest on seotud paljude brauseri müüja eesliidetega, mida kohtame üleminekul CSS2-lt CSS3-le. Jeffrey Way välja antud Nettuts+, mis sisaldab detailne info täielikult kasulikest parameetrilistest segudest koosneva faili rakendamise kohta. Artikkel hõlmab teie lemmik-CSS3-suvandeid koos müüja eesliidetega. Näiteks lihtne mikser erineva kujuga ümarate nurkade juhtimiseks:

Border-radius(@raadius: 3px) (
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @radius;
}
IN sel juhul, on klassi ".border-radius" raadius vaikimisi 3 pikslit, kuid saate sisestada mis tahes väärtuse ja saada ümarad nurgad. Näiteks ".border-radius(10px)" ümardab nurki 10 piksli võrra.

Sassi süntaks on väga sarnane LESS-iga. Lihtsalt kasutage muutujate jaoks "$" ja kutsuge mixinid, kasutades "@mixin" ja "@include" meetodeid, mida ma varem mainisin.

Valija pärimine

Vaatame midagi, mida LESSil ei ole. Selle funktsiooni abil saate rakendada valija varem seatud valijale, ilma et peaksite kasutama komadega eraldatud vormingut.

Menüü (
ääris: 1px tahke #ddd;
}

Jalus (
@extend .menu;
}

/* renderdab nii: */
.menu, .footer (
ääris: 1px tahke #ddd;
}
Pesastatud reeglid

Klasside ja ID-de hargnemine CSS-is on tõenäoliselt Parim viis kaitsta oma kaskaadlaadilehti segamise eest või vastupidi, suunata need suhtlema teiste lisatud tabelitega. Aga see lähenemine võib sageli hõlmata palju koodi. Kasutades selektorit nagu “#site-body .post .post-header h2”, saame väga kena välimusega koodi, mis võtab üsna palju ruumi. LESS-iga saate hargneda ID-sid, klasse ja elemente, nagu soovite. Kasutades ülaltoodud näidet, saate teha midagi sellist:

#site-body ( ...

Järelpäis (...

&:külastatud ( … )
&:hõljuma ( … )
}
}
}
}
Ülaltoodud kood on absoluutselt identne eelmises lõigus mainitud inetu valijaga, kuid seda on palju lihtsam lugeda ja mõista ning see võtab palju vähem ruumi. Samuti saate elemente stiilida, et viidata nende pseudoelementidele, kasutades "&" - sel juhul on see funktsioon sarnane JavaScripti "this"-ga.

Operatsioonid

See on umbes see, mida ootate: täpsete arvude või muutujate kasutamine matemaatilised tehted stiilides.

@base_margin: 10px;
@double_margin: @base_margin * 2;

@full_page: 960px;
@half_page: @full_page / 2;
@kvartal_leht: (@full_page / 2) / 2;
Muide, ma tean, et võin ka elemendid 4-ga jagada ja saada tüüpi muutujad"@quarter_page", kuid ma tahaksin näidata, et sulgude reegel sobib ka siin. Sulud on nõutavad ka siis, kui soovite sooritada toimingu parameetri piires. Näiteks "ääris: (@width / 2) solid #000".

Sass on numbrite osas palju mitmekülgsem kui LESS. See oli sisse ehitatud teisendustabelitesse, et kombineerida võrreldavaid ühikuid. Sass suudab töötada ja tuvastada määratlemata mõõtühikuid. See vara võeti kasutusele, et teha kindlaks raamatukogu asjakohasus W3C tehtud muudatuste suhtes.

/* Sass */
2 tolli + 3 cm + 2 tk = 3,514 tolli

/* VÄHEM */
2 tolli + 3 cm + 2 tk = viga
Värvide funktsioonid

Mainisin varem, kuidas LESS mind minuga aitab värviskeem koodi kirjutamise protsessis. Sellega on lahutamatult seotud ka lillede funktsioon. Oletan, et kasutate tavalist Sinine värv kogu oma stiilidokumendis ja soovite seda värvi rakendada oma vormi esitamisnupule. Saate avada Photoshopi või mõne muu redaktori, et saada sealt kuueteistkümnendväärtus (veidi heledama või tumedama värvi puhul). Või võite lihtsalt kasutada VÄHEM pakutavat värvide funktsiooni.

Esita (
polsterdus: 5px 10px;
ääris: 1px tahke @sinine;
taust: -moz-linear-gradient(top, lighten(@blue, 10%), @blue 100%); /*Moz*/
taust: -webkit-gradient(lineaarne, keskel üleval, keskelt alt, from(helenda(@sinine, 10%)), color-stop(100%, @sinine)); /*Webkit*/
taust: -o-lineaarne-gradient(ülemine, heledamaks(@sinine, 10%) 0%, @sinine 100%); /*Ooper*/
taust: -ms-linear-gradient(top, lighten(@blue, 10%) 0%, @blue 100%); /*IE 10+*/
taust: lineaarne gradient(ülemine, heledamaks(@sinine, 10%) 0%, @sinine 100%); /*W3C*/
värv: #fff;
text-shadow: 0 -1px 1px rgba(0,0,0,0,4);
}
Funktsioon "Heleda" muudab värvi sõna otseses mõttes heledamaks protsendiskaalal. Sel juhul muudab funktsioon põhisinist heledamaks 10%. See meetod võimaldab muuta gradueeritud elementide ja muude sama värvi elementide värvi, muutes lihtsalt põhivärvi enda. See võib pakkuda teile tühjendusprotsessis märkimisväärset jõudu. Lisaks, kui kasutasite parameetrilist funktsiooni (nagu ülalkirjeldatud), saate oma brauseri eesliiteid lihtsamaks muuta, muutes need näiteks ".linear-gradient(lighten(@blue), @blue, 100%) ;".

Teisest küljest saate päris kena efekti:


Nii saime muutujal põhineva kauni gradueeritud nupu Esita.

Värvide tumendamiseks või värvi muutmiseks on ka teisi värvifunktsioone, samuti värviratta pööramiseks teistele värvidele. Soovitan teil neid proovida, et teada saada, millised funktsioonid on teile kõige kasulikumad.

Tingimused ja kontroll

Veel üks üsna kasulik asi, mida pakutakse VÄHEM. Sassiga saate kasutada nii if ( ) else ( ) tingimustingimusi kui ka ( ) silmuseid. See toetab operaatoreid "ja", "või" ja "mitte", aga ka "", "=" ja "==".

/* Sassi "if" lause näidis */
@if heledus($värv) > 30% (
taustavärv: #000;
) @else (
taustavärv: #fff;
}

/* Sassi "for" tsükli näidis */
@for $i 1px kuni 10px (
.border-#(i) (
ääris: $i soliidne sinine;
}
}
Nimeruumid

Nimeruume saab kasutada CSS-koodile teise kihi lisamiseks, mis võimaldab meil luua tavaliselt kasutatavate stiilide rühmi ja seejärel need käigult valida. Näiteks kui lõime stiilide rühma nimega "vaikeväärtused", saame sellest rühmast valida, mida vajame teatud elemendi töötlemiseks.

#defaults (
.nav_list() (
loendi stiil: puudub;
marginaal: 0; polsterdus: 0;
}
.button() (…)
.tsitaat () ( … )
}
Järgmiseks, kui kohtame oma koodis elementi "nav" sees "ul", teame, et vajame vaikestiili. Seega saame seda hõlpsasti rakendada.

Navul (
#defaults > .nav_list;
}
Reguleerimisala (arvestatud raamistikku)

Piiride arvestamine programmeerimisel on norm, seega on see sama norm VÄHEM. Kui määrate muutuja kaskaadlaadilehe juurtasemel, on see saadaval kogu dokumendile. Kui aga alistate muutuja ja lisate selle id või klassi valijale, on see saadaval ainult selle väärtusega selles valijas.

@värv: #00c; /* sinine */

#header (
@värv: #c00; /* punane */

Ääris: 1px ühevärviline @color; /* on punase äärisega */
}

#footer (
ääris: 1px ühtlane @värv; /* on sinise äärisega */
}
Kuna me deklareerisime muutuja uuesti valijas "#header", on sellele muutujale eelnev väärtus erinev ja see on rakendatav ainult selles valijas. Kõik enne või pärast seda säilitab algse deklaratsiooni tähenduse.

Sassi ulatust tehakse veidi teisiti. Kui muutuja "@color" muudetakse ülaltoodud koodis punaseks, tõlgendatakse seda nii, nagu see on koodis.

Kommentaarid

See osa on üsna lihtne. Väljas LESS on kaks kehtivat kommentaaritüüpi. Standardne CSS-i kommentaar “/* kommentaar */” on kehtiv ning seda töödeldakse ja seejärel esitatakse. Üherealised kommentaarid "//kommentaar" töötavad ka, kuid neid ei kajata ega väljastata. Seetõttu võib neid sildistada "vaikivad".

Import

Ka import on üsna standardne. Standardne "@import: "klassid.vähem";" töötab päris hästi. Kui aga impordite mõne muu VÄHEM faili, on faililaiend valikuline. Seega "@import "klassid";" töötab ka hästi. Kui soovite importida midagi ilma töötlemisetapita VÄHEM, võite kasutada .css-laiendit (näiteks "@import: "reset.css";").

Stringi interpolatsioon

Stringandmeid saab kasutada ka muutujatena ja kutsuda stiili sees, kasutades "@(nimi)".

@base_url = "http://coding.smashingmagazine.com";
background-image: url("@(base_url)/images/background.png");
Põgenemine

Mõnikord peate lisama väärtuse, mis CSS-i süntaksis ei kehti või mida LESS ei tunne. Sageli tekib see olukord siis, kui Microsofti toodete rakenduse töö normaliseerimiseks on vaja rakendada mingit häkki. Vigade ja VÄHEM krahhi vältimiseks peate need välistama.

klass(
filter: ~"progid:DXImageTransform.Microsoft.Alpha(opacity=20)";
}

/* Väljastatakse tegelikult järgmiselt: */
.class(
filter: progid:DXImageTransform.Microsoft.Alpha(läbipaistmatus=20);
}
javascripti hindamine

See on üks minu lemmikosadest LESS-iga töötamise kohta: JavaScripti stiilides on nii lihtne kasutada. Saate kasutada avaldisi ja viidata ka arenduskeskkonna funktsioonidele, kasutades tagasimärki (`).

@string: `"tervist".UpperCase()`; /* @string muutub "HOWDY" */

/* Sa saad kasutage ka eelnevalt mainitud interpolatsiooni: */
@string: "tere";
@var: ~`"@(string)".topUpperCase()`; /* muutub "HOWDY" */

/* Siit pääseme osale dokumendist */
@height = `document.body.clientHeight`;
Väljundi vormindamine

Kuigi LESS-il pole väljundvalikuid, pakub Sass 4 väljundversiooni: hargnenud, kompaktne, tihendatud ja laiendatud.

Alumine joon

Neil kahel suurel raamatukogul on palju sarnasusi. Mõlemad on suurepärased tööriistad disaineritele, kes koodi arendavad, ning aitavad ka arendajatel tõhusamalt ja kiiremini töötada. Kui olete Ruby või HAMLi fänn, siis Sass on kindlasti teie jaoks. Mis puudutab mind (ja mina PHP arendaja ja javascript), jään VÄHEM, kuna seda on palju lihtsam integreerida ja ka JavaScripti väljenditele ja dokumendiatribuutidele juurde pääseda. Kahtlen, kas ma olen stiilitabelite kujundamisel kunagi tõsiseltvõetavaid programmeerimisoskusi kasutanud, kuid arvan, et see on proovimist väärt. Kui olete mõlemat raamatukogu kasutanud, siis kuulen hea meelega teie mõtteid ja nõuandeid! Meie ressurss võtab alati hea meelega kommentaare!