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

Zdroják » Webdesign » CSS preprocesory: méně psaní, vyšší efektivita

CSS preprocesory: méně psaní, vyšší efektivita

Články Webdesign

Kaskádové styly doprovázejí naše stránky již půl druhé dekády. Za ta léta jsme si stačili velmi dobře všimnout jak jejich nesporných výhod, tak i nevýhod, které především kodérům znesnadňují práci. Pojďme takové klacky pod nohama zdolat, projít si třeba jarní LESS a nadechnout se opět čerstvého kodérského vzduchu.

Kde se vzaly styly

První specifikace CSS vyletěla z hnízda W3C v roce 1996. Umožňovala tvůrcům HTML stránek nejen vyčlenit čistě prezentační značky a atributy do nového deklarativního jazyka, ale také používat grafické prvky, jaké v tehdejším HTML ani vytvořit nešly, nebo jen velmi složitě. CSS1 zavádělo fonty, barvy, pozadí, různé dekorace a řezy písma, padding a margin, základní pozicování a první selektory. Druhá specifikace přinesla lepší absolutní a relativní pozicování, z-index, první media typy, nové selektory a další vylepšení.

Na historii CSS si lze všimnout dvou zajímavých jevů. Styly se mnohdy inspirovaly nějakými rutinními, ale velmi často v praxi používanými technikami a snažily se je nahradit vlastní, většinou mnohem jednodušší deklarací. Například zavedení pseudotřídy :hover vytlačilo JavaScript z obarvování odkazů při najetí myší. Podobné posuny lze vidět v připravovaném standardu HTML5, kde např. atributy formulářových prvků mají v budoucnu nahradit stávající robustní skripty pro zobrazování kalendářů.

Druhým jevem, který nelze opomenout, je fakt, že veškeré dobré snahy specifikací CSS byly vždy bržděny implementacemi v prohlížečích. Vyrostli jste na „žluté bibli kaskádových stylů“ od Petra Staníčka? Jen si vzpomeňte, jak jste studovali přehledové tabulky a naráželi na samé -- nebo dokonce !!!. Bez viny však nezůstává ani samotné W3C. Málokdo ví, že v současné době vlastně nemáme žádnou finální specifikaci CSS, které bychom se mohli závazně držet. CSS1 bylo po dvou letech od vzniku nahrazeno CSS2, ale i to bylo brzy prohlášeno za zastaralé. W3C totiž vydalo CSS2.1, které opravuje chyby a řeší některé nedostatky. To však dodnes nedospělo do stavu hotového doporučení…

Slabiny CSS

V horských kaskádách utekla spousta vody od prvního návrhu jazyka, označovaného jako CSS. Od té doby se samozřejmě vyvíjel, ale v podstatě pouze přidáváním vlastností k prezentaci HTML elementů. Odráží tento vývoj ale skutečný posun světa webdesignu? Opravdu je jediným rozdílem to, že designéři jsou dnes mnohem smělejší a při návrhu webu se nemusí jejich výtvarná duše tolik krotit?

Dnes máme obrovské weby s mnoha složitými a velkými styly, máme webové aplikace a styly pro spousty různých zařízení. Jejich správa přerůstá nejen možnosti direktivy @import, ale i trpělivost kodérů, kteří se někdy místo samotné práce musí věnovat spíše otrockému kopírování, přepisování CSS deklarací a psaní složitých dokumentačních komentářů. Když si přečtete první a druhý článek Martina Michálka na téma „udržovatelný stylopis“, tak jistě pochopíte, o čem je řeč. Jak ale zajistit spravovatelnost a udržovatelnost CSS a vyhnout se mechanické dřině?

CSS3 nás nespasí

Shrneme-li dosavadní poznatky, zjistíme, že máme s CSS dva zásadní problémy. Jednak fakt, že specifikace a implementace nestíhají reagovat na překotný vývoj webu, jednak ona zmiňovaná těžkopádná správa. První z těchto problémů řeší CSS3. Oproti předchozím jednodokumentovým specifikacím je tato rozdělena na mnoho částí a je opravdu rozsáhlá. Vzhledem ke zkušenostem z vývoje CSS2.1 lze sice očekávat, že jejího oficiálního dokončení se nedožijí ani naši vnuci, ale naštěstí jsou některé moduly už prakticky ve finálním stavu a další vlastnosti prohlížeče experimentálně implementují už dnes.

Jak určitě víte ze seriálu Webdesignérův průvodce po CSS3 od Honzy Sládka, můžeme se těšit na spoustu nových vlastností a zmiňované experimentální funkce lze používat s tzv. „vendor prefixy“. Jen pro připomenutí, překlad tohoto slovního spojení z kodérštiny do češtiny je „použití na vlastní nebezpečí“. A jak Honza popisuje v článku Graceful degradation vs. progressive enhancement, s takovým nebezpečím se šikovný kodér vyrovná i na komerčních webech, kde většinou experimentovat moc nemůže. „Hurá!“ jásáme a ženeme se na nové voňavé CSS vlastnosti, ještě horké z trouby. Prostudujeme CSS3.info, poprosíme u okýnka na css3please.com a neseme si domů plný košík křupavých novinek. Třeba takový barevný přechod:

background-image: -moz-linear-gradient(top, #444444, #999999); /* FF3.6 */
background-image: -ms-linear-gradient(top, #444444, #999999); /* IE10 */
background-image: -o-linear-gradient(top, #444444, #999999); /* Opera 11.10+ */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999)); /* Saf4+, Chrome */
background-image: -webkit-linear-gradient(top, #444444, #999999); /* Chrome10+, Saf5.1+ */
background-image: linear-gradient(top, #444444, #999999);
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444444', EndColorStr='#999999'); /* IE6–IE9 */

Toto celé je použití jedné jediné vlastnosti. Na pohled lákavý a křupavý obsah košíku rychle tvrdne, stejně jako úsměv na rtech kodérových. CSS3 nám sice přineslo hromadu pěkných věcí, ale při jejich použití vás od trhání vlasů zachrání jen plešatost.

CSS jako kompilovaný jazyk

Jste zoufalí? Měli jsme dva problémy, jeden jsme vyřešili žhavou novinkou, ale ta přinesla zase jinou obtíž. A protože nám W3C nepomůže, jsme pravděpodobně odsouzeni k věčnému psaní a kopírování CSS deklarací. Nebo nejsme?

Naštěstí nejsme! Na scénu se snáší deus ex machina, konkrétně překladač. Když uděláme ze stylopisů kompilovaný jazyk, zmíněné strasti to vyřeší. Dokonce si ani nemusíme nic sami na koleně programovat, protože to již dávno udělal někdo před námi. Komu tento nápad přijde povědomý, jistě si vzpomene třeba na článek o LESS, jehož obliba i u nás pomalu roste. CSS je jazyk čistě deklarativní, což se sice pro popis vzhledu webové stránky náramně hodí, ale zároveň nás to omezuje ve znovupoužitelnosti a v praktikování přístupu označovaného jako DRY („neopakuj se“). Nově navržené jazyky jako LESS proto do stylů přináší něco málo z imperativního a objektového programování. Jak vám řekne každý OOP programátor, především ona objektovost rapidně zvyšuje možnosti správy a udržovatelnos­ti kódu.

Překladačů CSS existuje již řada. Nejznámějšími jsou Sass a LESS, ale najdeme i další, např. JavaScriptový Stylus nebo CleverCSS, napsané v Pythonu. Abychom pochopili rozdíly mezi Sass a LESS, nakoukněme znova v rychlosti do historie.

Sass vznikl roku 2007 v komunitě okolo HAML, což je jazyk pro zjednodušený zápis HTML. Jeho úkolem bylo zjednodušit a rozšířit CSS. To první se povedlo hlavně tím, že využili nápady z HAML a syntaxi stylů oprostili od céčkovských závorek a středníků. Naopak význam dostalo odsazení a nové řádky. Ne každému však tento způsob zápisu vyhovoval, a tak vznikl v roce 2010 LESS, který má zápis stoprocentně vycházející z původního CSS. To k němu přitáhlo hodně lidí, jelikož šlo snáze zkoušet nové vlastnosti a nebylo zapotřebí se učit úplně nový jazyk. Sass nezaspal a brzy uvedl alternativní syntaxi nazývanou Scss, také vycházející z CSS. Sass/Scss je na světě delší dobu, má nyní i onu CSS syntaxi, je pro něj více nástrojů a kolem něj větší komunita, takže dnes už důvod rozhodnout se pro LESS není tak jednoznačný.

Co nám překladače umožňují? Zavádějí proměnné, výpočetní výrazy, objektové „mixins“ a dědičnost selektorů, vnořování pravidel a mnoho dalšího. Přitom vám stále zůstává i mocný nástroj v podobě kaskády. Podrobně jsou tyto vlastnosti popsány jak v odkazovaném článku o LESS, tak třeba na úvodní stránce Sass, takže by bylo zbytečné je zde všechny znova prezentovat. K podnícení fantazie se však bude hodit popis jejich použití.

Proměnné výhodně použijete na výčet barev nebo šířek bloků. Výrazy a vestavěné funkce vám pak pomohou s jejich použitím – nebudete již muset sčítat okraje a šířky, napíšete prostě jen margin-left: 20px + $aside-width a je to. Podobně na barvu textu se může hodit color: darken(@cocacola-red, 10%);.

Určitě jste také již kódovali styl pro nějakou zvláštní část stránky a po chvilce jste zjistili, že vám deset pravidel pod sebou začíná např. .footer. V takovém případě jistě oceníte vnořování. Objektové vlastnosti vám umožňují deklarovat si kousky kódu a pak je opakovaně používat na mnoha místech a dokonce i dědit od nich. Bystřejší už vědí, že přesně toto budou chtít použít na rozložité střípky CSS3. Použití pak bude jednoduché:  .rounded-corners(10px);.

Kdy a jak překládat?

Pokud z nekompilovaného jazyka uděláme najednou překládaný, vyvstává otázka: kam do životního cyklu naší webové aplikace umístit onen překlad? Pokud má použitý nástroj k dispozici interpretovaný překladač v JavaScriptu, jako třeba LESS, můžeme jej připojit ke stránce v hlavičce jako běžný skript a rovnou poslat web do ostrého provozu. To je sice velmi snadné a rychlé, ale sami si jistě dokážete představit, že by bylo lepší, kdyby vám styly fungovaly i bez zapnutého JavaScriptu nebo kdybyste měli lepší kontrolu nad možnými chybami.

Druhou možností je využít překladač napsaný v nějakém serverovém jazyce. Pokud web stejně poběží na Djangu, RoR nebo Nette, nabízí se vyhledat preprocesor CSS implementovaný v Pythonu, Ruby nebo PHP a začlenit jej přímo do projektu. To sice umožňuje větší vládu nad stylem, například přidávání CSS pravidel dynamicky „za běhu“, nicméně nalezení vhodného překladače pro konkrétní jazyk není leckdy jednoduché. Po GitHubu jsou sice k nalezení desítky různých implementací, ale jen málokterá je opravdu kvalitní nebo udržovaná. Problémy mohou být také s tím, že si autor portovaného překladače upraví při portování i samotný jazyk. Například pro PHP existuje lessphp s aktivní komunitou a pěknou dokumentací, ale jeho LESS používá na oddělování parametrů středníky místo čárek. Vámi psaný LESS je potom nekompatibilní, a tím pádem nepřenosný.

I když se vyrovnáte s tímto faktorem, pravděpodobně vám brzy začne vrtat hlavou otázka, zda a jak výsledek překladu kešovat, aby se překládalo jen jednou.

Asi nejlepší možností je proto nainstalovat si do svého počítače přímo původní kompilátor jako běžný program a využívat jej k překladu stejně jako v případě jakéhokoliv jiného jazyka. Na ostrou verzi webu potom samozřejmě kopírujeme jen výsledné CSS styly, nejlépe i komprimované, tedy bez bílých znaků. Sass nainstalujete jednoduše jako balíček, tzv. gem, do Ruby a poté můžete překládat z příkazové řádky: sass print.scss print.css. LESS byl původně v Ruby také, takže pro něj rovněž naleznete gem, ale pokud chcete jeho nejnovější verzi, musíte sáhnout po JavaScriptu. K ruce vám v tomto případě bude Node.js, jehož instalace je ale zatím o něco složitější. Používáte-li při vývoji verzovací systém, můžete si pak k jeho jednotlivým úkonům automatický překlad CSS „přilepit“ jako tzv. hook. Kdyby vám to nestačilo, Sass má k dispozici nástroj, jemuž řeknete, kde máte svoje sass/scss soubory a on hlídá jejich změny. V reálném čase je potom kompiluje do CSS a vám stačí k pozorování změn jen aktualizace stránky v prohlížeči.

Balíky z budoucnosti

Pokud jste začali nějaký CSS preprocesor používat a píšete v něm CSS3 deklarace, možná vás napadlo, že by stačilo vytvořit nějaký balík mixinů pro každou z experimentálních vlastností CSS3 a ten postupně jen doplňovat, promítat do něj změny v prohlížečích a dolaďovat jej pro jejich různé verze. Že to vůbec není špatný nápad si myslí i lidé kolem projektu Compass, což je celý framework vybudovaný nad vlastnostmi jazyka Sass. Škála jeho nástrojů je obsáhlá a udržovaná, obsahuje snad všechny dnes použitelné věci z CSS3 a dokonce umí spolupracovat s oblíbeným CSS frameworkem Blueprint. Pro LESS se také objevil pokus o podobnou knihovnu s názvem Bootstrap.less.

Výhodou pro běžného kodéra je pak i skutečnost, že nemusí experimentální vlastnosti udržovat aktuální sám – stačí, když jednou za čas nahraje novou verzi odladěného frameworku.

Shrnutí

Kaskádové styly oblékají naše stránky již pěknou řádku let a časem se zákonitě projevily jejich slabiny. Problém pomalého rozšiřování stylovacích schopností jazyka snad odstraní průbojné CSS3. Nedostatečnou podporu v prohlížečích neovlivníme tak snadno, ale můžeme si pomoci experimentálními vlastnostmi. Ty nám ale zkomplikují další nedostatek, a to už tak špatnou spravovatelnost, udržovatelnost a znovupoužitelnost stylopisů. Jako zajímavá cesta se jeví právě popsané preprocesory, které zjednodušují, zpřehledňují a rozšiřují CSS. Musíme pak sice styly (nezvykle) překládat, ale na druhou stranu do rukou dostaneme velmi silný nástroj a zbavíme se drtivé většiny důvodů, proč si při psaní CSS zoufat.

Za povšimnutí stojí i fakt, že podobný trend se dnes objevuje např. i u JavaScriptu – nedostatky návrhu se zde snaží řešit CoffeeScript. Opět se jedná především o tzv. syntaktický cukr, takže bychom jej mohli klidně nazvat „preprocesorem JavaScriptu“.

Komentáře

Subscribe
Upozornit na
guest
11 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
alancox

Myšlenku CSS nadnesl Nor Lie.

CSS jako první implementoval Microsoft v Internet Exploreru 3.

V té době ještě W3C nevydala žádný standard ani standard CSS ani neexistoval. Ba dokonce ani W3C v té době netušila, že nějaký CSS bude mít vůbec pod palcem.

W3C se pak svezla na vlně plivání na Microsoft a schválně navrhovala CSS styly tak a řadu vlastností aby byly byť jen drobně nekompatibilní s Internet Explorerem a to přečasto tam, kde kromě nenávisti k Microsoftu to nemělo žádný důvod.

W3C pak svou aroganci předvedla ještě několikrát. Například v CSS 1 je napsáno, že gramatika CSS se nebude v budoucích verzích měnit, aby se hned v příští verzi drobně pozměnila.

Díky svým naschválům se pak Microsoft rozhodl, že počká až se blbci ve W3C vybouří se svých pubertálních žertíků a tím si W3C efektivně zajistilo 10 let odkladu v nějaké jednotné kaskádovací implementaci.

To je podstatně přesnější a méně tendenční historie začátků CSS, která vysvětluje základní principy a historii začátku.

Dlouhán

Tak se nám tu sešly dvě historie, jedna tendenční a druhá ještě víc.

jAM_jAM

Ponkrac musi mit pravdu, rekli mu to hvezdy.

Hm
JH

Implementace CSS v MSIE 3.0 byla strašná. V roce 2000 jsem dělal jeden firemní web, MSIE 5.0 byl na svém vrcholu, Netscape skomíral a slibný projekt Mozilla někde ve verzi M14. Byl to první projekt ve kterém jsem opustil klasický tabulkový design a vrhnul se na free-cool-in CSS.

Tehdy jsem narazil na problém, protože půlka té fimy používala MSIE 3.0 (což mě ani ve snu nenapadlo). A použití kaskádních stylů způsobilo, že stránka v MSIE 3.0 se rozsypala do horní části obrazovky a byla naprosto nečitelná… Stížnosti uživatelů se naštěstí vyřešili upgradem prohlížeče :)

Druhý problém na který jsem tehdy v té firmě narazil a na který jsem byl upozorňován vícero uživateli bylo, že stránka neobsahovala něco jako tlačítko „ODEJÍT“ a to uživatele mátlo…

ykarr

Bože, tlačítko „Leave the page“! To byly časy!

stratos

Velmi pekne shrnuti.

asdasd

O zvýšení přehlednosti několikanásobným zanořením stylů bych se sice hádal, ale možnost používat konstanty a makra je skvělá vychytávka, to mi v css vždycky chybělo.

MW

To zanořování může být dobré proti hloupým chybám – např. selektor #id .trida .trida2 h1, h2 dělá pravděpodobně něco jiného, než autor zamýšlel.

Pepa

věta „nalezení vhodného překladače pro konkrétní jazyk není leckdy jednoduché. Po GitHubu jsou sice k nalezení desítky různých implementací, ale jen málokterá je opravdu kvalitní nebo udržovaná“ neplatí zdaleka obecně.

Například v Ruby, a konkrétně v RoR, nasazení Sass obnáší dopsání řádku » gem „sass“ « a změnou koncovky souborů .css na .sass. S tím že v nadcházející verzi Rails lze první krok již vynechat (Sass je default). Less se v ruby/rails světě moc nepoužívá, pokud vím.

Problém Less oproti Sass je údajně ten, že Less není čistý superset css (=v některých mezních případech nestačí přjmenovat .css na .less). A includování preprocesoru na client-side taky není ideální řešení.

Taky bych doplnil, že tento týden vyšla nová verze sass s některými zajímavými pokročilejšími možnostmi.

kahi

Rád bych si přečetl i praktické zkušenosti a dojmofakta z používání preprocesorů… Kdyby redakce dostala takovýto článek, prosím neodmítat! :-)

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.