Jednoduchost technologie špatný kód neospravedlňuje

„Ach, kdyby jen specifikace CSS obsahovala proměnné!” a další geekovské povzdechy si můžeme odpustit, protože a) právě teď nic takového CSS neobsahuje a b) není jisté, že by to CSS bordelářům skutečně pomohlo. Myslím si, že jednoduchost je velmi dobrá vlastnost jakékoliv technologie, CSS nevyjímaje.

Hezky to dříve popsal Honza Sládek, takže pro argumenty zajděte k němu. My můžeme pokračovat směrem k návrhu řešení palčivé otázky.

Jak z jednotlivých opakujících se pravidel extrahovat informaci o typech písem, barvách či layoutu obecně používaném na webu tak, aby stylopisy splňovaly alespoň základní parametr udržovatelnosti — že jim bude rozumět sám autor, když se ke své práci za tři měsíce vrátí?

Jelikož se snažím se upřednostňovat jednoduchá řešení a vyhýbat se vrstvení technologií, z našich úvah vyřazuji CSS preprocesory jako LESS, čímž ale neříkám, že pro ně nevidím uplatnění.

Poněkud tupý, přesně takový jaký jej chceme — manuál stylopisu

Po mnoha pokusech se mi nakonec obrovsky osvědčila úplně nejtupější varianta — manuál v externím souboru. V adresáři se stylopisy u každého svého projektu najdu soubor README.txt, ve kterém všechny potřebné informace jsou. Kdykoliv pak na webu vytvářím nový prvek, podívám se sem a zjistím jaké by měl mít vlastnosti.

Obsah manuálu

Pojďme se podívat co takový manuál stylopisu může obsahovat.

• Kontakty na autora
• Seznam souborů a jejich obsah
• Písma a jejich varianty 
• Index z-indexů
• Barvy a jejich varianty
• Rozměry opakujících se prvků laoyutu
  

Než plýtvat detaily, odkážu vás na tři své manuály stylopisu, které jsou součástí projektů vyrobených v Shortcat studiu.

BioOKO Pražské jaro Hipposdesign.com

Jedna část manuálu tedy nahrazuje velmi málo se vyskytující manuály designu a také vizuální identity. Další část supluje nedokonalost CSS jako technologie — například pro varianty barev  budeme moci brzy začít široce využívat RGBa. Index z-indexů a varianty písem zase sjednocují na jedno místo informace, které bývají rozptýlené po různých pravidlech ve stylopisu.

Manuál stylopisu v žádném případě nenahradí dobře organizovaný, komentovaný a srozumitelně psaný CSS kód. Přidává vrstvu abstrakce, kterou kaskádové styly neumožňují.

Milí čtenáři, více než jindy zde ocením váš feedback a vlastní zkušenosti se správou CSS.

Jednoduchost technologie špatný kód neospravedlňuje

„Ach, kdyby jen specifikace CSS obsahovala proměnné!” a další geekovské povzdechy si můžeme odpustit, protože a) právě teď nic takového CSS neobsahuje a b) není jisté, že by to CSS bordelářům skutečně pomohlo. Myslím si, že jednoduchost je velmi dobrá vlastnost jakékoliv technologie, CSS nevyjímaje.

Hezky to dříve popsal Honza Sládek, takže pro argumenty zajděte k němu. My můžeme pokračovat směrem k návrhu řešení palčivé otázky.

Jak z jednotlivých opakujících se pravidel extrahovat informaci o typech písem, barvách či layoutu obecně používaném na webu tak, aby stylopisy splňovaly alespoň základní parametr udržovatelnosti — že jim bude rozumět sám autor, když se ke své práci za tři měsíce vrátí?

Jelikož se snažím se upřednostňovat jednoduchá řešení a vyhýbat se vrstvení technologií, z našich úvah vyřazuji CSS preprocesory jako LESS, čímž ale neříkám, že pro ně nevidím uplatnění.

Poněkud tupý, přesně takový jaký jej chceme — manuál stylopisu

Po mnoha pokusech se mi nakonec obrovsky osvědčila úplně nejtupější varianta — manuál v externím souboru. V adresáři se stylopisy u každého svého projektu najdu soubor README.txt, ve kterém všechny potřebné informace jsou. Kdykoliv pak na webu vytvářím nový prvek, podívám se sem a zjistím jaké by měl mít vlastnosti.

Obsah manuálu

Pojďme se podívat co takový manuál stylopisu může obsahovat.

• Kontakty na autora
• Seznam souborů a jejich obsah
• Písma a jejich varianty 
• Index z-indexů
• Barvy a jejich varianty
• Rozměry opakujících se prvků laoyutu
  

Než plýtvat detaily, odkážu vás na tři své manuály stylopisu, které jsou součástí projektů vyrobených v Shortcat studiu.

BioOKO Pražské jaro Hipposdesign.com

Jedna část manuálu tedy nahrazuje velmi málo se vyskytující manuály designu a také vizuální identity. Další část supluje nedokonalost CSS jako technologie — například pro varianty barev  budeme moci brzy začít široce využívat RGBa. Index z-indexů a varianty písem zase sjednocují na jedno místo informace, které bývají rozptýlené po různých pravidlech ve stylopisu.

Manuál stylopisu v žádném případě nenahradí dobře organizovaný, komentovaný a srozumitelně psaný CSS kód. Přidává vrstvu abstrakce, kterou kaskádové styly neumožňují.

Milí čtenáři, více než jindy zde ocením váš feedback a vlastní zkušenosti se správou CSS.

Cituji z článku Roberta Nymana o objektovém CSS:

As you might be aware of, using good semantics is very important to me, and when it comes to both elements being used as well as the naming of CSS classes, I believe it should contain a meaning for what it will contain. OOCSS contains class names like .leftCol, .rightCol, .body, .h1, .h2 etc. And to me, and what I believe is to be in line with the notion of the semantic web, is that one of the fundamentals with CSS class names is to not use class names which describes the actual presentation/layout, but rather what it will contain.

…

But, I suggested using other names that would have more meaning and be easy to understand at the same time, like .main-heading, .complementary etc. The reply I got was that she had tried it, but “It was too hard for people to remember it”. And that I’m mot just buying. Sure, .rightCol might be a tad easier to remember, but just going the easiest route time doesn’t always make it right.

Všimněme si, že autoři se při argumentaci k používání obsahově popisných názvů tříd zaštiťují správností a odkazem na sématických web. Ale co je správné, pro koho a v jaké situaci, že?

Myšlenka sémantického webu — jako světa kde stejný typ informací je stejným způsobem označen — je samozřejmě ve velkém množství situací užitečná. Musí ale usnadňovat orientaci v kódu za účelem pochopení obsahu nejen strojům, ale především lidem.

Nicolle Sullivan, autorka OOCSS, se rozhodla, že názvy tříd v jejím CSS frameworku budou blíže vizuálnímu vnímání (říká hezky „vizuální sémantika”) než klasicky vnímané sémantice obsahové. Tedy .leftCol raději než .complementary.

Být autorem CSS frameworku — tedy technologie jejíž použití vnímám nikoliv univerzálně, ale velmi specificky — rozhodnu se stejně.

Argumentem mi bude právě čitelnost a zapamatovatelnost. Vždyť jak jinak bych chtěl svůj framework rozšířit mezi lidi! Jak jinak bych chtěl, aby jej bez manuálu v knižním vydání a vyfintěných PDF-taháků na populárních webdesignérských serverech používal také někdo jiný než autor sám?

V HTML/CSS kódu psaném na míru obsahu dávám vždy přednost pojmenování tříd takovému, aby co nejvíce odpovídaly významu obsahu, ale v konkrétních případech je lepší dát přednost popisu vizuální prezentace.

Nedělejme ze sémantiky univerzálně platné náboženství. Žádné takové neexistuje ani ve webdesignu.

Krásně se sice nabízí čerstvá modla webových typografů, @font-face, ale zdá se, že pro tisk vlastních fontů má tahle technologie má nejlepší léta ještě před sebou.

Udělal jsem dneska komplexnejší test na OpenType.info demostránce. Vše na Windows XP:

• Firefox 3.5.5 — vlastní fonty tisknout nelze a asi ještě chvíli nepůjde (viz Martinův tweet) namísto fontu definovaného ve @font-face tiskne systémový
• Opera 10.01 — tiskne stejně hezky jako zobrazuje
• Safari 4.0.4 — na místě, kde mají být @font-face písma, netiskne vůbec nic!
• Chrome 3.0 — @font-face zatím vůbec neumí

Na této testovací stránce pak můžeme vyzkoušet jak jsou na tom v Redmondu:

• IE 7 + 8 — fonty vkládáné jejich technologií EOT tiskne krásně

Vidíme tedy, že mimo Operu a Internet Explorer jsou minimálně na Windows prohlížeče zatím neschopné tisknout jinými než v lokálním operačním systému instalovanými fonty.

Kdo máte možnost vyzkoušet prohlížeče na Macu, napište prosím do komentářů.

Legrace, že obecně se má za to, že s @font-face lze vlastními fonty tisknout krásně. Kromě nevyhlazování písem na systémech bez antialiasingu se zdá, že se jedná o druhý výrazný nedostatek téhle výborné ale zatím k masovému nasazení nezralé technologie.

Jiný rytmus

Baseline se od ostatních (mně známých) liší hlavně principem vertikálního gridu. Blueprint a další jsou založeny na „přilepování prvků” k opakující se výšce řádku (line-height). Baseline jako jednotku vertikálního rytmu volí baseline, nebo-li česky účaří.

Typografové by k tomu asi mohli říct více po řemeslné stránce. Osobně můžu mluvit spíše o příjemnějším pocitu zejména v hezké provázanosti nadpisu první až třetí úrovně s následným textem.

A když necháme emoce stranou, můžeme říci, že v případě zarovnání na účaří bude pro kodéry jednodušší nalezení nechtěných odchylek.

Nalevo opět Blueprint, napravo Baseline:

Když se podíváme na celou vyrenderovanou stránku, vidíme že Baseline ztrácí svou eleganci u nadpisu 5. a 6. úrovně (ale kdo z vás je naposledy skutečně použil?), pak v případě použití divu uprostřed textového bloku (to taky není příliš častá situace).

Baseline se ve srovnání tváří ošklivě na formulářové prvky. On je hezké umí, ale musíte mu dodat zvláštní HTML kód. Ano, srovnání v případě formulářů ztrácí trochu smysl, ale pokud třeba prototypujete a nechcete upravovat HTML, hodí se to vědět.

HTML5 ano, IE6 ne

S Baseline sice dostanete i nějaký horizontální grid pro tvorbu layoutu, nicméně nemám pocit, že by na něj byl kladen důraz. Každopádně v balíku dostanete PSD s mřížkou a podporu nových prvků HTML5. Autor (Stéphane Curzi) se naopak rozhodl, že nebude trávit noci s laděním frameworku pro MSIE 6.

Baseline CSS je pro mě svou lehkostí jako základ pro stavbu uživatelského rozhraní webu velkou konkurencí Blueprintu. Budu si ale dávat pozor na možné rozdíly v prohlížečích, na které autor upozorňuje. Naopak bych ho nedoporučil pro prototypování. Tam raději sáhnu po Blueprintu, Bluetripu nebo Tripoli.

Na ose designér — kodér — programátor najde Baseline využití někde mezi designérem a kodérem.

Nejlépe je na tom Blueprint CSS, kde - alespoň podle Githubu - skupina vývojářů neustále něco kutí. Jsou to ale spíše drobnosti nebo “věci kolem” a od první verze Olafa Bjorkoye se vlastně nic zvláštního nestalo.

Takový 960 je na tom podobně - podívejte se na blame hlavního CSS souboru na Githubu a uvidíte, že od únorového počátečního pushe Nathan Smith poslal jen nějaké drobnosti.

Poslední změna v YAML CSS pochází z ledna a je pravděpodobné, že takto bychom mohli pokračovat.

Je možné, že potenciální možnosti vývoje univerzálních CSS frameworků v jejich současné podobě jsou vyčerpané a dále se budou vyvíjet spíše frameworky jednoúčelové nebo ono ulehčování práce s CSS půjde spíše směrem metajazyků typu SASS. Co myslíte?