Přejít k navigační liště

Zdroják » Webdesign » Směřuje CSS od preprocesingu k postprocesingu?

Směřuje CSS od preprocesingu k postprocesingu?

Články Webdesign

Blíží se soumrak CSS preprocesorů? Jakou roli v hrom hraje postprocesing? Přečtěte si krátké zamyšlení.

Nálepky:

Článek původně vyšel na autorově webu Vzhůru dolů.

Preprocesory přišly s řadou užitečných vlastností a vyplňují potřeby, které samotné CSS nezvládalo uspokojit. Přišel ale Grunt a Gulp, změnily se naše pracovní postupy a některé důvody pro preprocesory se tím vytratily.

Sám dnes CSS preprocesory používám prakticky pro všechny projekty. Souběžně s neutuchajícím nadšením pro LESS a jeho partu u mě ovšem probíhá postupný ústup od všech jejich pokročilých vlastností.

Vyvrcholením trendu bylo zamyšlení, zda preprocesory vůbec potřebuji. Tenhle skvělý článek od Cole Peterse mě pak přinutil sepsat nynější stav mysli.

Potřebuji preprocesory? Zatím ano, hlavně kvůli proměnným

Vezměme to po jednotlivých základních vlastnostech:

@import a slučování do jednoho souboru

Skvělá věc, protože krátí dobu načítání stánek. Umíme ale vyřešit i bez preprocesorů. Nějakým css-concat podobně jako u Javascriptů.

Mixiny pro CSS3 vlastnosti

Prefixované vlastnosti nám jednu dobu docela zatápěly, že jo? Dneska už to takový problém není. Navíc máme Autoprefixer. Postprocessing jako vyšitý.

Zanořování deklarací

„Dobrý sluha, ale zlý pán” tady platí úplně nejvíc. Pro nezkušené kodéry by bylo lepší, kdyby tahle vlastnost nikdy nevznikla. A s metodikou OOCSS to preprocesorové zanořování zas tak nepotřebují ani ti zkušení.

Matematika

V LESSu jsem si dost oblíbil třeba percentage(2/3). Bez preprocesorové matematiky bych ale přežít dokázal. Nativní funkce calc()hezkou podporu.

Cykly, podmínky, extend a další vlastnosti

Počkejte, vy je vážně používáte? :-) Ale jo, uznávám, že nastavení týmu a projektu může být takové, že jsou pro vás nepostradatelné. Chápu, pokud děláte CSS animace nebo grid systémy. Tvrdím ale, že pro většinu užití preprocesorů jde o zbytný syntaktický cukr.

Proměnné

Tady se nechávám poddat. Těžko je něčím nahradíte. Aktuálně používám preprocesory hlavně kvůli nim. Ale blýská se na lepší časy, ještě chvíli čtěte.

Nevýhody CSS preprocesorů

  1. Až moc silný nástroj – odklon od tuposti CSS a příliš mnoho abstrakce sice vede k propracovanému, někdy až imperativnímu kódu. Zároveň často ale špatně čitelnému a spravovatelnému.
  2. Proprietární kód – pokud preprocesory využíváte „tupě“, je zaučení nového člověka nebo přechod na jiný preprocesor relativně jednoduché; horší je to ovšem v kombinaci s prvním bodem.

Postprocessing s cssnext

Všimněte si, že téměř všechny uvedené základní vlastnosti preprocesorů — s čestnou výjimkou proměnných — dnes umíme nahradit s pomocí Gruntu.

Hlavní výhoda následného zpracování je v tom, že CSS píšeme v dnešní syntaxi. Případně v syntaxi standardizované, ale prohlížeči zatím neimplementované.

Podívejte se hlavně na projekt cssnext. Ano, W3C.org připravuje standard pro CSS proměnné, matematiku, vlastní media queries a další. A díky CSSnext je budete moci využívat už dneska. Třeba proměnné:

.box {
  --text-color: black;
  color: var(--text-color);
}

Vracíme se tedy k deklarativní a (v dobrém smyslu) tupé povaze jazyka. Vyhýbáme se přílišné abstrakci preprocesorů. Náš kód bude snáze naučitelný a přenosný, protože jsme se zbavili jeho proprietární, nepřenosné syntaxe. A s vysokou pravděpodobností je dopředně kompatibilní.

Postprocessing přitom to není nic nového. Sám pomocí Gruntu do CSS už pěkných pár měsíců přidávám pixelový fallback pro rem jednotku, prefixované verze vlastností nebo generuji CSS pro prohlížeče, co neumí Media Queries.

Pro postprocessing mluví i možnost výběru sady vlastností. Sami můžete říct, zda CSSko obohatíte jen o proměnné, nebo i něco dalšího. A kromě jiného si tím také brutálně zrychlit kompilaci.

Tohle všechno ještě před pár lety nebylo možné. Nebyl Grunt, Gulp a nekonečné množství jejich pluginů. CSS se pod taktovkou W3C skoro nevyvíjelo. Postupy jako OOCSS nebo BEM používala jen hrstka zasvěcených. Do tehdejšího světa preprocesory zapadaly zcela dokonale.

Pojďme to vyzkoušet

Na papíře vypadá postprocessing skvěle. Musí se ale ověřit praxí. Nevím jak vy, ale já to jdu zkusit hned na příštím projektu.

Komentáře

Subscribe
Upozornit na
guest
17 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Aleš Roubíček

Dalším krokem pro rozumný vývoj webových alikací je zbavení se globálních stylů a požití lokálních deklarací pro konkrétní komponenty. Nějaký náznak je ve WebComponents/Polymeru ale taková komponenta je změtí divného HTML/CSS/JS. Dalším řešením je React CSS, který rezignoval na CSS a stylopisy se píšou v JS. Zkoušel jsem to chvíli používat a výsledný (v browseru) kód je opravdu obludný.

Co mě ale zaujalo je použití css-loaderu ve WebPacku. Tento loader umožňuje načítat styly, které potřebuje konkrétní komponenta, tak, že v kódu omponenty uděláme import stylů:

import styles from '../css/components/foo';

Ve vazbě styles pak máme jako vlastnosti jednotlivé třídy definované ve stylopisu. Ve stylech pak použijeme selector :local:

:local(.my-foo-style) { }

Loader pak může dělat s takovým názvem co potřebuje. Tj. vygeneruje globálně unikátní název případně ho může i snadno minifikovat. Pro nás ale zůstává kód stále čisté CSS.

Ve spojení se zmiňovaným cssnext, konečně použitelné řešení na udržovatelné styly pro webové aplikace.

Aleš Roubíček

Ještě jsem zapomněl zmínit jednu nevýhodu superlokálního CSS alà React CSS a tou je kontext, který globální selektory zvádají snadno, ale v Reactu se musí předávat jako stav a horkotěžko vypočítávat.

BorisLetocha

Vysledny kod v browseru nemusi byt vubec obludny …
Viz http://bobris.github.io/Bobril/style/index.html, kde Bobril Style dynamicky generuje css a treba i prebarvuje ikonky. To znamena ze lze pouzit veskerou silu JS a optimalnosti aplikovani class v browseru.
Pro React si pak vyberte obdobnou knihovnu zde: https://github.com/MicheleBertoli/css-in-js

Ivan Nový

K tomu, aby se věci měnily na jednom místě, nikoliv na padesáti, když potřebujete upravit vzhled stránky. Což je hlavní nevýhoda deklarativních jazyků. Grafický návrh stránky by měl začínat návrhem css mixinů, dekompozice na jednotlivé objekty by se měla udělat ještě před samotným grafickým návrhem. Dnes je prvotní funkce stránky, design jsou jen její šaty a ty musí být jednoduše zaměnitelné.

tacoberu

K tomu, aby se věci měnily na jednom místě, nikoliv na padesáti, když potřebujete upravit vzhled stránky. Což je hlavní nevýhoda deklarativních jazyků.

Cože?! Měl jsem za to, že je to přesně naopak. Deklarativní jazyky jsou vrcholem abstrakce. Popisování věcí (na jednom místě) patří mezi jejich doménu.

karel

Ano dost daklarativnich jazyků je vrcholem,
sranda často končí když chete pracovat smysluplně a mimo hranice tutorialu

Aleš Roubíček

V ideálním světe by to tak mohlo fungovat, praxi se osvědčily přesně opačné přístupy. Mixiny se vytvářejí refactoringem opakujících se konstrukcí. Jednotlivé objekty se utvářejí během životního cyklu a často se měmí. Grafický návrh se vyvýjí společně se zbytkem. Jen to asi není statický bitmapový obrázek.

Ivan Nový

A měly by. Zobecnit to samozřejmě jde. Když se dříve psaly texty v editorech, bylo rozumné předem vytvořit styly, které se pak používaly místo ad hoc stylování v textu. Navíc je to vhodné i z hlediska orientace uživatele, který najde na daném místě to co očekává, protože to už viděl jinde, na jiné stránce. Originalita za každou cenu je nesmysl.

Ivan Nový

Tak zrovna ten první odkaz má rozumnou strukturu, která se skládá z dobře definovatelných stylů, bistroagency je nesmysl, Třetí je sice příliš dlouhé, ale styly by se definovat rovněž daly, i když graficky je to tragické, nikde tam není zachovaný zlatý řez, což působí odpudivě. Co nelze vytvořit z „lega“ stylů, je nepochopitelné i pro konzumenta a emoce to už nespraví a ani se nedostaví. Filmový střih taky není nic jiného, než budování emoce z „lega“ obrazů, na základě kontrapunktu, totéž funguje v grafice. Symbolika obrazů musí být navázána na nějaké archetypy, aby to bylo srozumitelné, i film je jazyk, a tedy jazykem je i rozpohybovaná webová grafika. A základem každého jazyka jsou základní lexikální jednotky, „slova“, ze kterých se skládá významová věta. Ve webové grafice přece efekt pohybu dosahujete tím, že vezmete nějakou základní jednotku stránky a u té změníte její grafické parametry. Tedy nejlépe na jednom místě definujete tyto jednotky, které mohou být a jsou znovupoužitelné a jen podle potřeby měníte jejich parametry. A na to jsou dobré mixiny a aritmetika, kterou ale neobsahuje css. Záměrně, protože se původně soudilo, že je dobré, aby css bylo čistě deklarativní, což se ukázalo jako chyba.

Radek Tůma

Proč úplně zavrhovat preprocesor? Pokud se držím zásady zanoření maximálně 4 úrovně, používám-li složené deklarace na začátku – mimo „zanořený“ kód, mám více (v mém případě LESS) souborů (např. layout.less, navigation.less, fonts…), což také omezuje hlubší zanořování; které pak pomocí @imports vkládám do centrálního stylopisu, výrazně mi to ušetří psaní. Zároveň výsledný CSS po kompilaci je poměrně štíhlý. Orientace v kódu je díky zanořování, napodobujícímu DOM strukturu dokumentu jednodušší.

Říkám si, kdyby CSS od začátku umělo třeba to zanořování a proměnné, možná by se leccos zjednodušilo.

Ivan Nový

Přesně tak, navíc nedochází pak k vedlejším efektům, jako když upravíte globální pravidlo a kolikrát ani nevíte, kde všude se uplatní, protože stylopis má několik tisíc řádků a nedělal jste ho vy sám, a všechny kontexty selektoru si nepamatujete a ani neznáte. Díky zanoření úpravu omezíte lépe jen na danou konkrétní oblast reálně vygenerovaného DOMu, zvláště je-li jich více v daném kontextu.

Aleš Roubíček

problém globálních změn s neznámými důsledky řeší mnou odkazované řešení, ne zanořování a tím zneefetivňování selektorů, jen proto, aby měly větší specificitu.

Ivan Nový

Ano, ale zase na druhé straně těsná vazba lokálního css na komponentu vede k roztříštěnosti stylu. Často by bylo potřeba změnit styl, třeba velikost písma v nadpisu na jednom místě a ne to muset dělat ve všech komponentách. Přírozenější mi připadá uspořádání, kdy při vytváření grafického objektu máme k dispozici prefabrikované bloky (mixiny), ze kterých se objekt sestavuje, aniž by jim dával vlastní význam mimo dědičnost. Použiji-li někde mixin, implicitně souhlasím s tím, že nemám kontrolu nad tím, z čeho jsem grafický objekt vytvořil a pracuji s abstrakcí části vytvářeného grafického objektu, což mě přirozeně vede k takovému pozicování, které s možnou změnou mixinu počítá. Měl by tak vzniknout robustnější a lépe udržovatelný kód, kde se věci mění na jednom místě a celek zachovává automaticky jednotný styl.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.