Na nedávném setkání věnovaném CSS jsem se zeptala: “Kdo používá ve své každodenní práci Sass?”. Odpověď byla naprosto pozitivní; Sass už není vyhrazen jen pro hýčkané projekty a experimenty, rychle se stává standardním způsobem, jak psát CSS.
To je ale skvělá zpráva! Sass poskytuje mnohem větší moc nad složitými, stále narůstajícími stylovými předpisy, včetně nových schopností, jako jsou proměnné, řídící direktivy a mixiny, které původní specifikace CSS (úmyslně) postrádá. Sass je jazyk stylových předpisů, který je robustní, přesto dostatečně flexibilní, aby s námi držel krok.
Spolu s tím, jak se v širokém měřítku Sass zavádí (nad tím jásám), bohužel zároveň pozoruji neustálý pokles kvality produkovaného CSS (nad tím truchlím). Důvody jsou jasné: Sass vnáší mezi autora a stylové předpisy vrstvu abstrakce. A my potřebujeme do tohoto nového prostředí nějak překládat webové standardy — za něž tak úporně bojujeme. Potíž je v tom, že specifikace Sass expanduje natolik, že jakákoli sada standardů by vyžadovala neustálé přepracovávání. Proto je třeba disponovat něčím jiným, nějakou listinou — takovou, která se nachází vně Sass, přesto ale předkládá způsob, jak kódovat.
Prozkoumejme nejprve některá problematická místa
Jedním dobře zdokumentovaným nevhodným používáním sady schopností Sass je tendence přehnaně vnořovat CSS selektory. Abyste mě nepochopili špatně, vnořování je blahodárné; seskupuje kód tak, aby byla snadnější správa stylů. Problematičtější je hluboké vnořování.
Zaprvé, vytvářejí se jím dlouhé selektorové řetězce, které postihují výkon:
body #main .content .left-col .box .heading { font-size: 2em; }
Dále, může způsobit zaneřádění specificitou. Může nutit vytvářet dodatečné selektory s větší specificitou, aby překryly styly, které jsou výše v kaskádě — nebo nedej Bože nutí uchýlit se k !important:
body #main .content .left-col .box .heading [0,1,4,1]
.box .heading [0,0,2,0]
Stupňovaná specificita mezi dvěma selektory.
Konečně, vnořování může snižovat přenositelnost a udržovatelnost stylů, protože selektory jsou vázané k HTML struktuře. Pokud bychom chtěli zopakovat styl heading pro nějaký box, který nebyl v left-col, museli bychom napsat separátní pravidlo, abychom toho docílili.
Komplikované vnořování je patrně hlavním viníkem vytváření nechutné CSS polévky. Mezi další patří duplikování kódu a těsné vázání — opět jsou to výsledky nevalně zformovaného Sass.
Jak se můžeme naučit používat Sass uvážlivěji?
Jednou z možných voleb je vytvářet pravidla, která fungují jako limity a vládnou touto mocí jen do jisté míry. Například, Mario Ricalde se inspiroval filmem Počátek (Inception), když stanovil směrnici pro vnořování: “Choďte nejvýše čtyři úrovně hluboko.”
Pravidla jako je toto, jsou prospěšná zejména pro nově příchozí, protože poskytují jasné hranice, uvnitř nichž mají pracovat. Existuje však jen málo univerzálních pravidel; specifikace Sass stále expanduje a rozrůstá se (v době překladu je již Sass ve verzi 3.4.13, vydané 27.února 2015). S každým novým vydáním se zavádějí další schopnosti a s nimi přicházejí další provazy, na nichž se můžeme dobře oběsit.
Pouhá sada pravidel by byla neúčinná
Potřebujeme takový postoj k vývoji nejlepších praktik, který bude aktivnější a na vyšší úrovni, než jaký představuje pouhý důraz na hromadění jednotlivých pravidel. Mohl by být zformován jako:
- Kódové standardy neboli směrnice pro specifický programovací jazyk, které budou doporučovat programovací styl, praktiky a metody.
- Framework neboli nějaký systém souborů a složek standardizovaného kódu, který bude možno použít jako základnu pro nově tvořený web.
- Návody na styly neboli živý dokument kódu, v němž jsou všechny detaily různých elementů a kódových modulů webu nebo aplikace.
Každý z uvedených přístupů má jiné přednosti:
- Kódové standardy poskytují skvělý způsob, jak unifikovat tým a zlepšovat udržovatelnost v rámci rozsáhlé kódové základny (viz článek Návody na styly Sass, který napsal Chris Coyier).
- Frameworky jsou praktické a zároveň flexibilní, nabízejí nejnižší bariéru pro vstup a pro odstranění břímě rozhodování. Jak dobře ví každý příležitostný front-endový vývojář, i rozhodování o jménech CSS tříd se může stát vysilující úlohou.
- Návody na styly činí vztah mezi kódem a výstupem explicitním, ilustrují každou komponentu nacházející se uvnitř systému.
Každý z nich však vykazuje i určitá negativa:
- Kódové standardy jsou nepraktické. Musejí se udržovat stále aktuální a mohou se stát vstupní bariérou pro nové nebo nezkušené uživatele.
- Frameworky vykazují tendenci stát se přecpanými vším možným. Jejich flexibilita něco stojí.
- Návody na styly trpí tím, že jsou kontextově specifické; jsou jedinečné vzhledem ke značce, kterou reprezentují.
Tyto metody se bohužel vztahují k odborné stránce Sass a s naším skutečným problémem nám nepomohou. Naše obtíže se Sass nemají původ ve specifikaci samotné, ale vyplývají ze způsobu, jakým jsme se rozhodli ji používat. Sass je, konec konců CSS preprocesor; naším problémem se Sass je proto jeden, dílčí proces.
Takže, co nám zbývá?
Opětovná prohlídka pacienta
Každá činnost má své artefakty neboli lidské výtvory, potíže vznikají tehdy, pokud povyšujeme tyto vedlejší produkty nad finální výsledek dílčích prací. Musíme si uvědomit, že Sass pomáhá sestrojovat CSS, to však není koncovka partie, kterou hrajeme. Skutečně, pokud je úvod do CSS proměnných něco, čeho je třeba se držet, specifikace CSS a Sass začínají v tomto ohledu konvergovat, což znamená, že možná jednoho dne úplně Sass opustíme.
Co tedy potřebujeme, je nějaké řešení směrované ne na kód samotný, ale na nás, „praktické lékaře“ — něco, co nám poskytne odborné pokyny, když píšeme náš Sass, a zároveň pozvedne náš pohled směrem do budoucna. Potřebujeme veřejnou deklaraci záměrů a cílů, neboli, jinak řečeno, manifest.
Sass manifest
Když jsem poprvé objevila Sass, vyvinula jsem si jisté osobní směrnice. Časem se mi zformalizovaly do jistého manifestu, s nímž jsem pak mohla vyhodnocovat nové schopnosti a techniky — a zda jsou smysluplné pro můj workflow. To všechno začalo nabývat na důležitosti s tím, jak Sass rostl a jak ho můj tým začal mnohem víc používat.
Můj Sass manifest se skládá ze šesti principů, neboli artikulů, vypsaných níže:
- Výstup je víc než vstup
- Blízkost je víc než abstrakce
- Pochopení je víc než stručnost
- Konsolidace je víc než repetice
- Funkce je víc než prezentace
- Konzistence je víc než novelizace
Stojí za to připomenout, že jak bude specifikace dělat pokroky, mohou se rozvíjet i konkrétní aplikace jednotlivých artikulů. Artikuly samotné však musí zůstat nezměněné. Proberme teď důkladněji jeden po druhém.
1.Výstup je víc než vstup
Kvalita a integrita generovaného CSS je důležitější než předkompilovaný kód.
To je princip, od něhož se odvíjejí všechny ostatní. Uvědomte si, že Sass je jen jedním krokem na cestě k našemu cíli, jímž je doručovat soubory CSS prohlížeči. Tím není myšleno, že CSS musí být překrásně naformátovaný či skvěle čitelný (to se nikdy nestane, budete-li dodržovat nejlepší praktiky a minimalizovat CSS), při svých úvahách musíte vždy v prvé řadě myslet na výkon.
Až budete přebírat nové schopnosti ve specifikaci Sass, měli byste se sami sebe zeptat: “Jaký produkují CSS výstup?” Jste-li na pochybách, mrkněte se pod kapotu — otevřete zpracovaný CSS. Když budete důkladně rozumět vztahu mezi Sass a CSS, budou se vám snadněji identifikovat potenciální problémy s výkonem a budete svůj Sass patřičně strukturovat.
Například, pokud použijete @extend, terčem je každá instance selektoru. Následující Sass:
.box {
background: #eee;
border: 1px solid #ccc;
.heading {
font-size: 2em;
}
}
.box2 {
@extend .box;
padding: 10px;
}
se zkompiluje do:
.box, .box2 {
background: #eee;
border: 1px solid #ccc;
}
.box .heading, .box2 .heading {
font-size: 2em;
}
.box2 {
padding: 10px;
}
Jak vidíte, nedědil .box2 jenom z .box. .box2 dědil také z instancí, v nichž se .box používal v nějakém selektoru předka (ancestor selector). Je to jen malá ukázka, přesto názorně ukazuje, jak můžete dospět k neočekávaným výsledkům, pokud dobře nerozumíte výstupu z vašeho Sass.
2. Blízkost je víc než abstrakce
Projekty by měly být přenositelné, aniž by se musely příliš spoléhat na externí závislosti.
Vždy, když použijete Sass, vnášíte jistou závislost — i ta nejjednodušší instalace Sass závisí na Ruby a na gemu (pozn. RubyGems je systém pro správu softwarových knihoven Ruby. Takto zabalenému kódu se říká gem.) Sass. A mějte na paměti, že čím víc závislostí vnášíte, tím větší je riziko, že ohrozíte jeden z největších benefitů Sass: způsob, jakým umožňuje velkému týmu pracovat na témže projektu, aniž by si jeho členové vzájemně lezli do zelí a dupali po výsledcích práce ostatních.
Například, spolu s gemem Sass můžete nainstalovat hromadu extra balíčků, takže budete moci uskutečnit téměř jakoukoli úlohu, jakou si dokážete představit. Nejběžnější knihovnou je Compass (udržuje ji Chris Epstein, jeden z původních spolutvůrců Sass), můžete ale také nainstalovat gemy pro mřížkové systémy a frameworky, jako je Bootstrap, až po gemy, které pomáhají s mnohem drobnějšími úlohami, mezi něž patří vytvoření barevné palety a přidávání stínů.
Tyto gemy vytvoří sadu předem sestavených mixinů, z nichž pak můžete s výhodou čerpat ve svých souborech Sass. Na rozdíl od mixinů, které píšete uvnitř projektových souborů, gem se zapíše do instalačního adresáře vašeho počítače. Gemy se používají „tak, jak jsou“, podobně jako jádrové funkce Sass, a jediný odkaz na ně je přes metodu @include.
A zde to začíná být s gemy poněkud ošidné. Vraťme se ke scénáři, v němž celý tým přispívá do téhož projektu: jeden člen týmu, říkejme mu třeba John, se rozhodne, že nainstaluje nějaký gem, aby se usnadnila správa mřížek. Nainstaluje ten gem, zařadí ho do projektu, a použije ve svých souborech; mezitím jiná členka týmu — říkejme jí třeba Mary — vytáhne nejnovější verzi repozitáře, aby změnila fonty na webu. Stáhne soubory, spustí kompilátor, a z ničeho nic to skončí chybou. Od chvíle, kdy Mary naposled pracovala na projektu, John do projektu zavedl externí závislost; než bude Mary moci vykonat svou práci, bude muset chybu odladit a stáhnout správný gem.
Je jasné, že u většího týmu může tento druh potíží mnohonásobně narůst. Přidejme k tomu složitost udržování verzí a vzájemné závislosti gemů a rázem může vše přerůst do úděsných rozměrů. Pro projekty Ruby sice existují nejlepší praktiky, jak udržovat konsistentní prostředí, když se evidují a instalují jen nezbytně nutné gemy a verze, nejjednodušší přístup však je nepoužívat vůbec žádné dodatečné gemy.
Odvolání: v současné době používám knihovnu Compass, protože zjišťuji, že její přednosti převažují nad nevýhodami. Jak však jádro specifikace Sass dělá pokroky, uvažuji o tom, kdy řeknu Compassu sbohem.
3. Pochopení je víc než stručnost
Pište Sass kód jasně strukturovaný. Pořád myslete na vývojáře, který přijde po vás.
Sass je schopen vyplodit super zhuštěný CSS, takže nebudete muset klopotně optimalizovat předkompilovaný kód. Dále, na rozdíl od normálních CSS komentářů, inline komentáře v Sass nejsou součástí výstupu finálního CSS.
To je užitečné zejména tehdy, když dokumentujete mixiny, kde výstup není vždy transparentní:
// Vynutí uříznutí příliš dlouhých textů, například:
// @include truncate(100%);
// kde $truncation-boundary je nějaká společná (dohodnutá) velikost.
@mixin truncate($truncation-boundary){
max-width:$truncation-boundary;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
}
Rozhodně však uvažujte o tom, ze kterých částí vašeho Saas se má vyrobit finální soubor CSS.
4. Konsolidace je víc než repetice
Neopakujte se. Rozpoznávejte a sjednocujte opakující se vzory. Než začnete pracovat na jakémkoli projektu, je rozumné sednout si a pokusit se v designu identifikovat všechny různé moduly. Je to první krok na cestě k zápisu objektově orientovaného CSS. Některé vzory se nepodaří rozpoznat hned. Stanou se zřejmými teprve tehdy, až napíšete třikrát či čtyřikrát stejný nebo podobný řádek CSS. Jakmile rozpoznáte takové vzory, kodifikujte je ve svém Sass. Pro opakující se hodnoty přidejte proměnné: $base-font-size: 16px; $gutter: 1.5em; Pro opakující se vizuální styly přidejte zástupce (placeholder): %dotted-border { border: 1px dotted #eee; } Zapište mixiny, kde vzor přebírá proměnné: //průhlednost pro funkce obrázků
@mixin transparent($color, $alpha) {
$rgba: rgba($color, $alpha);
$ie-hex-str: ie-hex-str($rgba);
background-color: transparent;
background-color: $rgba;
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#{$ie-hex-str},endColorstr=#{$ie-hex-str});
zoom: 1;
}
Pokud si tento přístup osvojíte a zavedete, všimnete si, že menšími a lépe udržovatelnými se stanou jak vaše soubory Sass, tak i výsledný CSS.
5. Funkce je víc než prezentace
Volte takové jmenné konvence, které jsou zaměřené na funkci HTML, ne na jeho vizuální prezentaci.
Proměnné Sass se pro motiv webu vyrobí neuvěřitelně snadno. Ovšem až příliš často vidíme kód vypadající takto:
$red-color: #cc3939; //červená
$green-color: #2f6b49; //zelená
Napojit vlastní proměnné na jejich vzhled možná v tomto okamžiku vypadá rozumně. Co když se ale design změní a červená se nahradí jinou barvou? Dostanete se do situace, kdy název proměnné nebude v souladu s její hodnotou.
$red-color: #b32293; //fuchsinová
$green-color: #2f6b49; //zelená
Proto je lepším přístupem pojmenovat proměnné pro barvy podle jejich funkce na webu:
$primary-color: #b32293; //fuchsinová
$secondary-color: #2f6b49; //zelená
Prezentační třídy se zástupnými selektory
Co dělat, když nemůžeme nějakému vizuálnímu stylu přiřadit název třídy vyjadřující jeho funkci? Řekněme, že máme web a na něm dva boxy vysvětlivek (call-out box) pro kontakt a odkazy, “Contact” a “References”. Designér nastyloval oba boxy s modrým ohraničením i pozadím. My chceme u těchto boxů docílit co největší flexibility, ale zároveň minimalizovat jakýkoli redundantní kód.
Mohli bychom v HTML zvolit řetěz tříd, ale to by bylo dost restriktivní:
<div class="contact-box blue-box"> <div class="references-box blue-box">
Vzpomeňte si, že jsme si řekli, že se chceme spíše soustředit na funkci než na prezentaci. Naštěstí to lze hravě vyřešit metodou @extend Sass v součinnosti se zástupnou třídou (placeholder class):
%blue-box {
background: #bac3d6;
border: 1px solid #3f2adf;
}
.contact-box {
@extend %blue-box;
...
}
.references-box {
@extend %blue-box;
...
}
Vygeneruje se následující CSS, v němž už nikde nejsou vidět odkazy na %blue-box, předávají se dál pouze styly.
.contact-box,
.references-box {
background: #bac3d6;
border: 1px solid #3f2adf;
}
Tímto přístupem zredukujeme v HTML odkazy na názvy prezentačních tříd, v souborech Sass budeme přesto moci používat jejich vypovídající názvy. Když se budete násilně pokoušet vymýšlet funkční názvy pro všechny běžně používané styly, snadno nakonec dospějete k termínům jako base-box, který je zde mnohem méně vypovídající.
6. Konsistence je víc než novelizace
Nezavádějte do už zpracovaného CSS změny, které nejsou nezbytné.
Jestliže dychtíte zavést Sass co nejdřív do svého workflow, ale nemáte žádné nové projekty, asi vás zajímá, jak nejlépe zamontovat Sass do nějaké poděděné kódové základny. Sass plně podporuje CSS, takže na počátku je to směšně snadné, stačí změnit příponu z .css na .scss.
Poté, co učiníte tento tah, bude vás možná lákat rovnou se vnořit dovnitř a refaktorovat všechny soubory, oddělit je do speciálních souborů zvaných partial. (pozn. překl. Soubory obsahující fragmenty CSS, které se vkládají jiných souborů Sass direktivou @import. Název souboru musí začínat podtržítkem, takže Sass ví, že to je jen dílčí soubor, z něhož se nebude generovat CSS soubor.), vnořovat selektory a zavádět proměnné a mixiny. To však může průběžně způsobovat potíže všem těm, kdo si vytahují vámi zpracovaný CSS. Refaktorování nemusí mít žádný vliv na zobrazování čehokoli na webu, vygeneruje však zcela odlišný CSS soubor. A může být nesmírně obtížné jakoukoli takovou změnu izolovat.
Nejlepší způsob, jak se přepnout do workflow Sass, je aktualizovat soubory za pochodu, ale až to bude nutné. Potřebujete-li změnit navigaci, oddělte nejprve tuto část do samostatného souboru partial, a až pak na ní začněte pracovat. Zachováte tak kaskádu a později budete moci mnohem snadněji přesně identifikovat jakékoli provedené změny.
Prognóza pro Sass
Doufám, že naše momentální těžkosti se Sass jsou jen potíže růstu. Jsou to symptomy změn v myšlení, které musíme udělat, když přecházíme na nový způsob práce. Účinnou léčebnou kúrou je správně pochopit a dobře zvládnout Sass, pak budeme vyléčeni, protože ho budeme používat řádně.
Mojí vizí je, že tento manifest nám pomůže zorientovat se na cestě, po které kráčíme: používejte ho, změňte ho, nebo si napište vlastní — začněte ale tím, že se soustředíte na to, jak psát kód, ne na to, co právě píšete.
O autorce
Felicity Evans
Felicity Evans je front-endová vývojářka pro Fairfax Media, žije v Sydney v Austrálii. Miluje jídlo, barvy a tvorbu věcí pomocí pixelů. Tu a tam také tweetuje pod jménem @webfliccy.
Článek byl přeložen se souhlasem Alistapart.com
Původní článek: A vision for our Sass
- Translation: RNDr. Jan Pokorný
- Language and expert collaboration: Marek Machač
