Udržovatelný stylopis: pořádek v souborech, pozor na hacky a !important
Udržovatelnosti kaskádových stylů prospívá také konzistence ve struktuře souborů, jejich pojmenovávání a obsahu. A víte, proč jsou hacky z pekla? Opět z osobní zkušenosti, tedy subjektivně.
Nálepky:
Dnešní článek patří do rubriky Subjektivně. Jejím cílem je zejména poskytovat prostor pro názory a pohledy na aktuální dění v oblasti webových technologií i na jejich vývoj do budoucna. Jedná se o osobní názory, které se nemusí vždy shodovat s názory redakce. Pokud máte co říct, pojďte k nám psát Subjektivně.
Posledně jsme v článku Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava popsali hlavní zásady udržovatelného stylopisu. Dnes k nim přidáme několik rad.
Hacky a dobrý kód nejsou kamarádi
Hacky vnímám jako konstrukce, které využívají chyb prohlížečů. V pekle, kde jsou kodéři nuceni pracovat se špatným kódem, jsou nejbližšími Luciferovými pomocníky.
Hacky jsou vázané na konkrétní chyby konkrétních verzí prohlížečů, a tak nikdy nevíme, co se s nimi stane za měsíc nebo rok. Můžeme jen čekat a pak se divit, jako když nejznámější hack — podtržítkový pro IE6 — přestal fungovat v IE7. Nikdy nevíme, co s naším hackem provede některá příští verze prohlížeče.
Hacky v drtivé většině slouží pro rozpoznání MS Internet Exploreru, typicky jeho šesté verze. Toho však daleko lépe dosáhneme podmíněnými komentáři, kterým se budeme věnovat dále.
Jak důležité je šetřit s !important
„Nikdy není tak zle, aby bylo !important”, říkám si raději pokaždé. Klauzule !important zajistí, aby vlastnost nebyla nikdy v budoucnu přepsána. Může se hodit, ale většinou se zneužívá pro „tvrdé přebití” hodnoty nějaké vlastnosti. Jako pneumatickým kladivem na komára. Pro přebíjení máme naštěstí krásné pravidlo o podrobnějším selektoru.
Centrální stylopis, mozek našeho CSS
Centrální („bridging” nebo „housing”) stylopis je kromě „tiskového” a „explorerového” jediným, který linkuji z HTML hlavičky. Šetřím tím HTTP dotazy a také svoji práci při změnách nalinkování pluginů a frameworků z HTML. V centrálním stylopisu dodržuji jednotnou strukturu. Rychleji se v něm pak zorientuji, když se přepínám mezi různými projekty.
Co v něm najdete?
- Hlavičku
- Může se stát, že správu projektu po vás převezme někdo, kdo nebude mít možnost zjistit jeho autora. Uveďte zde popis stylopisu, název projektu a kontakt na sebe.
- Import frameworků
- Osobně zde typicky importuji resetovací a typografickou část Blueprintu.
- Import pluginů
- To když je potřeba využít cizí knihovny. Ty je lepší izolovat do vlastních CSS souborů a zde na ně odkazovat. Typickým pluginem v mém stylopisu je upravená verze FancyBoxu.
- Indexy
- V případě, že komentáře na produkční verzi automaticky odstraňujete, považuji za lepší je mít v centrálním stylopisu (soupis indexů najdete v minulém článku). V opačném případě je dejte do externího textového souboru.
- Helpery (pomocné třídy)
- Různorodí pomocníci, kteří jsou platní skrze celý projekt — definice vzhledu zpráv pro uživatele, externích odkazů, třídy označující načítání obsahu AJAXem nebo vývojovou verzi projektu.
- Layout
- Struktura layoutu celého projektu — hlavička, obsah nebo případně patička.
- Jednotlivé stránky
- Stránky nebo „šablony” společné pro více stránek si označím třídou nebo identifikátorem v <body> a buď zde definuji vzhled specifických prvků nebo předefinuji vzhled obecných prvků layoutu.
- Typografie
- Definice vzhledu prvků s textem. Myslím, že je rozumné si tyto prvky v dokumentu označit obecnou třídou a zde nadefinovat vzhled všech možných HTML značek. Zejména u částí, kde se vypisuje uživatelský obsah, je potřeba dopředu myslet i na katastrofické scénáře.
- Opakující se prvky stránek
- Například stránkování nebo fotogalerie.
Příklad hlavičky:
/*
Centralni stylopis webu Prazskeho Jara (www.festival.cz)
Autor: Martin Michalek, Studio Shortcat, michalek@shortcat.cz
*/
/* ===== Import Blueprint CSS a pravidel jej upravujich ===== */
@import "./blueprint.css";
@import "./blueprint-extra.css";
/* ===== Import pluginu ===== */
@import "./calendar.css";
@import "./fancybox.css";
@import "./sifr.css";
/* ===== Z-index "index" =====
Karusel:
1 .jcarousel-list - vsechny prvky karuselu
2 .jcarousel-clip - viditelna cast karuselu v jCarouselu
...
/* ===== Helpery ===== */
.loading
{
...
}
... CSS soubory mají stejné pojmenování a strukturu napříč projekty
Podobně jako ve struktuře centrálního stylopisu, i ve struktuře souborů považuji za nutné udržovat jednotnost. V mém adresáři CSS souborů pak najdete:
index.css— centrální stylopis. Mozek projektu. Pojmenujte si jej, jak chcete, osobně se rád sjednocuji s programátory.ie6.css,ie7.css— často jsem oba slučoval do ie.css, což ale není správná cesta. Každá verze potenciálně odlišného prohlížeče by měla mít vlastní stylopis. Jen tak definitivně utečete z pasti hacků.print.css— tiskové styly.blueprint.css— z Blueprint CSS využívám hlavně resetovací a typografická pravidla. Zde se hodí malá poznámka: využití jeho vlastností pro specifikaci layoutu mimo prototypování udržovatelnosti stylopisu spíše škodí, proto se jim u projektů poslední dobou vyhýbám.- pluginy a styly cizích knihoven (například
fancybox.css,sifr.css)
Příklad připojení stylopisu z HTML hlavičky
<link href="/css/index.css" media="all" rel="stylesheet" type="text/css">
<!--[if IE 6]><link href="/css/ie6.css" media="all" rel="stylesheet" type="text/css"><![endif]-->
<link href="/css/print.css" media="print" rel="stylesheet" type="text/css"> U menších projektů je možné tiskový stylopis přesunout do centrálního s pomocí pravidla pro oddělení média: @media print { ... }
Vyhýbám se colors.css a další slučujícím stylopisům
Někteří kodéři používají „dceřiné” stylopisy pro konkrétní typ pravidel — popis typografie, barev, rozměrů. Argumentem bývá oddělení pravidel, která se „mohou měnit”. Jenže…
- Všechna pravidla jednotlivých prvků jsou zpravidla spojité nádoby (typografie souvisí s barvou) a úpravy prvků na více místech nebývají právě radostné.
- Slučující stylopisy často vybízejí ke sjednocování definic prvků podobných vlastností, což je velmi nešťastné pro následné ladění (viz obrázek Firebugu).
- Změny v barevnosti lze udržovat lépe pomocí indexu barev a jejich nahrazováním v centrálním stylopisu.
Špatná optimalizace pro Firebug: Stylopis colors.css obsahuje pravidlo s příliš velkým počtem selektorů
Závěr
„Udržovatelností stylopisu” se zabývám asi rok a myslím, že aktuální stav mých myšlenek je spíše úvodem do problematiky než hotovým řešením.
Na podobné myšlenky jsem v posledních měsících narazil i u jiných — zabývá se tím například Russ Weakly nebo Natalie Downe. Prakticky celé současné hnutí kolem CSS frameworků žene dopředu snaha o zvýšení efektivity kóderské práce, kterého dosahuje i udržovatelný stylopis.
Martin Michálek se zabývá praktickým webdesignem od roku 1997. Posledních 7 let ve studiu Shortcat. Aktuálně se kromě jiného koncentruje na efektivitu webdesignérské práce. Píše blog Vzhůru dolů.
Martin Michálek
Nezávislý specialista na webový frontend. O responzivním designu, HTML5, CSS3 a dalších tématech píše na blogu Vzhůru dolů nebo v ebooku. Pořádá školení. Na Twitteru je jako @machal.
Ehm,… @import taky vyrobí další http request ;)
Ono to pak ale lze vcelku velmi jednoduše nějakým postprocesorem nas*at všechno do jednoho jediného souboru. Nicméně také jsem se divil, co že to tam píše. Ještě že tu máme HTTP/1.1 a nemusí se pro to zakládat další TCP spojení.
presne tak najlepsie je CSSka v PHPcku poskladat do jedneho suboru, a poslat to cele naraz.
boze chran nas pred silenejma WWW programatorama :))
CSS je programatorina jako remen
tu sa bavime o css, nie o programovani.
Si ho zlozil uplne. Toho programatora. Ktoreho vlastne?
Martine, píšeš:
Co je na Blueprint layoutu špatného? Tuším, že už si někde psal, že některé věci řeší BP dost svérázně. Můžeš to prosím trochu rozvést?
Díky.
Tak nevím, zda by pořádná odpověď nevydala na celý článek 8-)
Tím líp! S BP se mi osobně dělá velmi dobře, a zatím s ním žádnou negativní zkušenost nemám (nejsem ale kodér). Pokud BP trpí nějakými bolístky, rád bych si o nich něco přečetl…
Je to určitě na celý článek a o tématice CSS frameworků tady rád napíšu někdy příště.
Alespoň tedy stručně…
Blueprint a další 2-3 CSS frameworky co alespoň zběžně znám, tvoří layout na základě gridu a v HTML kódu pak kombinací tříd, kterými popisuješ vzhled, nikoliv obsah. V případě, že se frameworkem a jeho třídami pokusíš dělat v layoutu úplně všechno, můžeš dopadnou jako já, když jsem poprvé Blueprint nasazoval na starý layout Vzhůru dolů a skončil u konstrukcí jako
<div class="column span-6 prepend-1 indent-8 last">pro prvek, který se měl jmenovat třeba<div id="header">. :-)Na co jsou CSS frameworky skvělé, je prototypování. Když chceš rychle a čitelně vypsat nějaká data, musí pro tebe Blueprint být poslem z nebes. :-)
Začínám si myslet, že layoutové funkce Blueprintu (a spol) jsou skvělé pro programátory, nikoliv ale pro kodéry.
Aha!
Takže není problém v tom, že by BL konstrukce dělaly nějaké psí kusy v prohlížečích, ale spíš o čistotu HTML kódu. Vzhledem k tomu, že BL používám především na prototypování, pak mě to netrápí vůbec.
Díky za reakci Martine.
Začínám si myslet, že layoutové funkce Blueprintu (a spol) jsou skvělé pro programátory, nikoliv ale pro kodéry.
Ano, k tomuhle jsem pred nejakym casem rovnez dospel. Problem je, ze je programatori zatim jeste poradne neobjevili a pri tom by to pro ne byl dar z nebes.
Myslim ze to tak spatne neni, pokrokovi delnici klavesnic Blueprint znaji…
Ne, ono je to ještě horší, stačí se podívat všechny na ty vývojáře, co se HTML+CSS bojí a radši si zavolají kodéra, kdykoliv potřebují šablonu na jednoduchý formulář. Přitom s frameworkem by si nějaký prototyp udělali sami za pár minut a designér by to po nich pak jen pořádně předělal.
Zajímavý postřeh, který se snaží ukázat, že @import může být pomalejší než link: Don’t use @import.