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.

sIFR díky komplikovanému nastavování a velmi špatné rychlosti při načítání stránky postupně nahrazujeme jeho současnějšími sourozenci. Oba používají k náhradě canvas, respektive VML v Internet Explorerech a vypadají velmi podobně.

Který z nich zvolit? Na základě dostupných informací se rozhoduje jen těžce. Rozhodl jsem se pro vlastní hloubkový průzkum.

Ovládnout Typeface.js je snadné jako složit skříň z IKEA. Ale kdo by to chtěl dělat bez návodu?

Do dneška čistě intuitivně na všechny projekty používám Cufón. Dnes, při cíleném podrobném prozkoumávání Typeface.js jsem dospěl k tomu, že intuice byla v tomto případě jen synonymem pro dokumentaci.

Typeface.js můžete mít jako vývojáři na první pohled jen těžko rádi. Neexistuje pro něj prakticky žádný podrobnější manuál (na rozdíl od velmi slušně popsaného Cufónu.) Jako vývojářské rozhraní Typeface.js používá Launchpad, což je něco jako Github, kde sídlí Cufón. Ovšem Github z roku 2005.

Tady se znovu ukazuje, že chcete-li uspět jako geek, nestačí vám k tomu technické znalosti. Autoři Typeface.js svým přístupem k dokumentaci a absencí efektivního dialogu s komunitou svůj software dobrovolně degradovali do pozice hříčky, kterou berou vážně jen nadšenci do webové typografie.

Už v tuhle chvíli bychom mohli říct co je a co není dobrý software. Vyhrál by Cufón. Dejme ale Typeface.js ještě šanci.

Typeface.js: Pozor na licenční podmínky

Na webu Typeface.js si písmo vygenerujete poměrně snadno. Původně uměl jen TrueType formát, ten je teď doplněný o OpenType, který je výrazně rozšířenější u písmolijen. Formulář generátoru písma pro Cufón je naproti tomu složitější a zpočátku z něj budete asi docela na větvi.

Jedna z věcí, kterou Cufón ale umožňuje nastavit, je velmi užitečná — jde o omezení funkčnosti písma na určitou doménu. Náhradou písem pomocí sIFR nebo Cufón jste totiž obvykle na hraně licenčních podmínek většiny písmolijen i když vlastní licenci koupenou máte. Omezení na konkrétní doménu písmo alespoň trochu chrání před hromadným zneužíváním a s menšími písmolijnami se na něm určitě domluvíte.

Pokud písmo nahrazujete pomocí Typeface.js, buďte na pozoru. Omezení na určitou doménu nastavit nelze a tak budete pravděpodobně za hranicí toho, co bude vaše písmolijna ochotná překousnout. Raději se ptejte, protože někteří informovanější typografové užití písma pomocí Typeface.js dokonce vyloženě zakazují.

Implementace, rychlost — remíza

Výhodou Typeface.js je o fous snadnější implementace — k prvku, který chcete nahradit prostě přidáte class="typeface-js" a vše důležité si pak nastavíte ve vlastním stylopisu včetně řezu písma. CSS pravidlo pak může vypadat moc hezky i s dopřednou kompatibilitou: font-family: 'Můj řez písma', Arial, sans-serif.

Rychlost obou je v běžných případech srovnatelná. Javascript Typeface je pomalejší, když nahrazujete větší množství nadpisů. Testoval jsem 100 nadpisů na stránce, kde si vzal výkon Firefoxu na dobu o pár vteřin delší než Cufón a z pohledu uživatele byl jistý „zásek” znát.

Je ještě pár drobných rozdílů, které ovšem zrovna na vašem projektu mohou být zásadní:

Jelikož mám od Cufónu daleko dostupnější informace, budu dále standardně používat jej. Typeface.js ovšem nezahazuju a v případech kdy potřeba označit text myší bude zásadní a zároveň nebudu narážet na problém s licencováním, sáhnu po něm.

Důležité je, že oba dobře přebírají CSS vlastnosti nahrazovaných písem a jsou tedy vzájemně poměrně snadno nahraditelné. Nemusíte se tedy bát, že vás případný přechod na jinou technologii bude nějak zvlášť otravovat jako to mohlo být v případě sIFRu.

Kterou technologii používáte vy a jaký pro to máte důvod? Rád uslyším váš názor v komentářích nebo na Twitteru.

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.

Železničářské Ministerstvo propagandy v časech recese šetří a tak nezbyly dotace na další nadšenecký článek o Rails. Radosti se místy nelze ubránit i tak, nicméně čekejte i chvíle dojemného zklamání. Článek je určen všem, kteří si myslí, že programovat weby nedokáží, ale povědomí o technologiích mají. Skuteční programátoři, ušetřete si nervy a běžte jinam.

Ostatně, mé startovací znalosti nebyly úplně mimo mísu. S Ruby on Rails (RoR) kódem přicházím pasivně do styku už přes dva roky, znalosti HTML a CSS mě živí až trapně dlouho. Věděl jsem co je to MVC, dokážu použít if a (Rubysté, ruku na klobouk) také unless. Tyhle znalosti nejsou ale tak podstatné, rozhoduje angličtina a schopnost správně se zeptat Googlu. Komunita kolem Rails je nadšená, sdílná a umí učit.

Ačkoliv o prospěšnosti RoR pro webdesign dlouhodobě nepochybuji, dost jsem nevěřil své šanci vyrobit web sám a hlavně o čase, ve kterém jsem schopen se to naučit.

Podívejte se, jak jsem postupoval a jaké problémy přitom řešil.

Začínáme s prací na projektu

Jde o primitivní eshop. Jednotlivé produkty jsou tříděny do kategorií. Pomocí jednokrokového formuláře lze objednat právě jeden produkt.

Z pohledu technického má práce na webu takovýto postup:

1. Znalost obsahu a vztahů mezi jeho typy 
2. Správa obsahu 
3. Výpis obsahu do uživatelského rozhraní webu 

První krok: definice typů obsahu a vztahů mezi nimi

Ať už jste programátor nebo designér, nejdříve se musíte důkladně seznámit s obsahem, se kterým pracujete. Jeden typ obsahu je v našem případě jeden Model. V tomto konkrétním projektu máme tři základní Modely: kategorii, produkt a objednávku.

Musíte znát vazby mezi Modely. V našem případě: Jeden produkt má právě jednu kategorii. Jedna objednávka obsahuje jeden produkt.

Máte? Jako uživatel Windows bych si teď představoval, že mi pokročilá technologie pro tvorbu webu poskytne nějaký klikací nástroj, kde si typy obsahu a vazby mezi nimi nadefinuji. Ani v RoR tomu tak není. Rails mají  blíž k Linuxovému uživatelskému rozhraní, použijeme tedy příkazovou řádku a pomocí generátoru vytvořím Modely. Vazby mezi nimi si pak nadefinujeme ve vygenerováném kódu. Je to sice horší než klikání, ale vůbec to nebolelo.

Záměrně tady nemluvím o databázi, natož abych zmiňoval MySQL nebo jiné standardy. Výšeuvedeným postupem jsme vlastně databázi nadefinovali, ale Rails se o databázi starají jaksi samovolně. První věc, nad kterou jsem radostně výskal. 

Mám tedy jednoduchý nástroj pro definici typů obsahu, data se mi nějak budou ukládat, ale já se nemusím trápit se znalostmi MySQL, SQLLite nebo čehokoliv jiného. To je hned o jednu úroveň technického myšlení a řešení problémů během práce na celém projektu méně. Místo toho můžu ženě uvařit čaj nebo podrbat naši kočku. Wow.

Druhý krok: Správa obsahu

Strukturu obsahu máme. Teď budeme potřeboval jednoduché rozhraní administrace, kde chceme samotný obsah přidávat, upravovat a mazat.

Administrační rozhraní na jedno kliknutí? Mám smůlu

Moje představa: ve chvíli kdy v klikacím rozhraní „vyrábím” Modely, hledal bych zatržítko „Vygeneruj z nich jednoduché správcovské rozhraní”. Naivní? V Rails zatím ano.

Zatržítko neexistuje, nemám dokonce ani snadnou možnost jak správcovské rozhraní oddělit (do obligátního /admin nebo jinam) od rozhraní pro zobrazování dat. Rails totiž generují kostru (říká se tomu scaffolding) uživatelského rozhraní v jednom celku. Oddělit správu jinam samozřejmě lze, ale je to mravenční práce.

Tady jsem se myslím poprvé a naposledy ocitl na hranici svých schopností a nebýt pánů Karla Minaříka a Vlada Suchého, zřejme bych v tomto levelu hry ztratil všechny životy. Zdály se mi tady sny o Djangu, které sice neznám ani tak špatně jako Rails, ale které má generování správcovského rozhraní vyřešeno na pohled docela hezky. Ani v případě Rails ovšem nevěřím, že by komunita nechala administrace-chtivé kodéry dlouho na holičkách.

Trochu krve a potu a nakonec tedy jednoduché správcovské rozhraní máme.

Třetí krok: výpis obsahu do uživatelského rozhraní webu

Výpis samotných dat v šablonách (tedy Views) je něco kvůli čemu jsme celou tu věc dělali a jste-li kodérem, budete se tady cítit jako doma. Téma Rails a šťastný kodér je ale na úplně jiný článek. Tady se bavíme o problémech nešťastného začínajícího programátora.

Hodně mi zpočátku vadilo, že bych měl pro HTML prvky využívat Rails metody (například image_tag namísto ). Takové programátorštiny s divnou syntaxí v mém krásném HTML! Jenže porovnejte dva kusy kódu:

<% unless @product.image.blank? %>

<% end %>

a

<%= image_tag(@product.image) unless @product.image.blank? %>

Ten kdo vybere druhý případ není jen programátor, ale také člověk, který chce svůj kód zanechat čitelný a snadno pochopitelný. 

Migrace: olej do soukolí databáze, ale rozhraní nikoliv

Dobrá, máme nějaká data, máme jejich správu, máme výpis těch dat do uživatelského rozhraní webu. Jsme relativně šťastní, dokud… Dokud nepřijde zlý klient a neřekne, že do každého produktu by potřeboval přidat ještě anotaci a další obrázek.

Máme však výhodu, že myslíme agilně a Rails nás v tom podporují. On klient není zlý a jeho požadavek je zcela na místě. V Rails to jde samo — vytvoříme si migraci, kde ty dvě, tři pložky do databáze přidáme.

Jenže jak je přidáme do hotového rozhraní a administrace? Bohužel tušíte správně. Ručně. Svět není tak daleko, abyste se nepříjené práce nezbavili úplně. Docela by mě zajímalo, zda zrovna téhle prudy umí některá ze současných technologií zbavit.

Shrnutí: sami to určitě zkoušejte

Už dlouho se mi nestalo, že bych při adopci nějaké technologie propadal takovému jásotu nad vlastním pokrokem. Zkoušku Rails doporučuji všem kodérům, projektovým vedoucím, ale i techničtějším designérům nebo marketérům. Hlavně všem, kteří si při pohledu do PHP zdrojových kódu řekli, že „ne, to programování opravdu není pro mě”.

Berte mou chválu samozřejmě s rezervou, pokrok proběhl i jinde. Máme Django, CakePHP nebo Nette. Se všemi jsem přišel alespoň letmo do styku, leccos na nich oceňuji, ale nemám dostatečné znalosti abych byl schopen porovnání.

Soudě podle této zkušenosti s Rails, vyvíjet weby na míru bez hlubších technických znalostí zatím moc nejde, chcete-li se je ale naučit programovat, s Rails vám to může jít překvapivě snadno.

Jak u tebe vznikla potřeba zabývat se CSS frameworky? Přišel impuls z vlastní práce nebo tě oslovily diskuze mezi vývojáři?

Přišel s požadavkem jednoho z mých klientů, který potřeboval optimalizovat webovou stránku pro tisk. Strávil jsem asi měsíc zkoumáním obecné roviny čitelnosti, typografie a tisku webových stránek. Tak vznikl Hartija, univerzální stylopis pro tisk webových stránek. Jen jsem chtěl sdílet můj výzkum se světem.

Každý z mých CSS projektů má jiný příběh. Emastic jsem například vybudoval proto, aby zlepšil některé funkce „starých” CSS frameworků. Přidal jsem jsem navíc nějakou použitelnost, em-layout a pružný grid. Ve své době byl Emastic, jehož grid.css soubor měl jen 2kB, první frameworkem pro layout v kategorii lehké váhy.

Zajímavý je asi příběh CSS grid frameworku na jeden řádek (1 line CSS Grid Framework), který slouží pro budování layoutových systémů založených na 1, 2, 4, 8, 16 … sloupcích a který v CSS zabírá pouhý jeden řádek. Tento projekt nemá praktický účel v „reálném životě”, ale byl jedním z mých nejnavštěvovanějších projektů.

Geekové, zejména pak programátoři, jsou citliví na spojení „CSS framework”. Například v případě Hartija je otázka, zda je slovo framework na místě. Osobně mám pro ne-layoutové CSS projekty rád název užívaný v YUI knihovně - „základna”. Řešíš rozdíl mezi knihovnou a frameworkem nebo myslíš, že je to jedno?

Ano, to je pravda – programátoři říkají, že s CSS nemůžete vybudovat programátorské frameworky jako PHP framework nebo javascriptové frameworky.

A – na druhou stranu – CSS geekové říkají, že „CSS frameworkem” se může nazývat jen CSS knihovna s alespoň resetovací, layoutovou a typografickou funkcí.

Vynálezce pojmenování „framework”, Jeff Croft, řekl:

„Absolutně souhlasím. Jsem z toho také rozčílený. Mám pocit, že jsem udělal svým způsobem totéž když jsem psal ten článek pro ALA (A list Apart, pozn. překl.), ale (nevědomky) jsem mu dal velmi polarizující jméno („CSS framework”), které od té doby posunulo diskuzi špatným směrem. Lidé se stali tak posedlí svou averzí na slovo „framework”, že ignorovali hlavní myšlenku článku: že společné návrhové vzory a znovupoužitelný kód je udělají efektivnějšími.”

Takže nemáme standard co vlastně „CSS framework” je a pokud jasné standardy neexistují, je velmi těžké určit, kdy název „CSS frameworky” používat.

Podle mého názoru CSS frameworky vytvářejí znovupoužitelný CSS kód vyšší úrovně.

Tedy každá CSS knihovna, která vytváří znovupoužitelný CSS kód vyšší úrovně, může být nazývána frameworkem.

Když se podívám na typografické vlastnosti tvých CSS frameworků, vidím, že v porovnání s ostatními obsahují určitou osobitost a subjektivitu. Blueprint, Baseline a ostatní se snaží především o čitelnost a subjektivitu nechávají na autorovi stránek. Nemyslíš, že to je nevýhoda tvých frameworků, která brání širšímu použití?

Typografie v Emastic byla pro mě výsledkem hledání perfektní webové typografie. Experimentoval jsem s Arialem a Georgií, které jsou asi nejpoužívanějšími fonty na webu. Vždy s snažím míchat různá písma pro nadpisy a pro obsah. Proto jsem použil Georgii pro nadpisy a Arial pro text.

Emastic je postaven na vertikálním rytmu založeném na základním účaří („baseline grid”, pozn. překl.). Pokud tedy máte pružný sloupcový layout a pokud chcete, aby typografie fungovala dobře v téměř všech případech, může být soubor typography.css z Emastic dobrou volbou. Strávil jsem hodiny jemným dolaďováním Arialu s cílem zlepšit čitelnost a jasnost. Uvnitř Emastic najdete také plugin gadgets.css, který přidává nějaké extra vlastnosti jako barevnou paletu nebo jiné malé „gadgety”.

Tady je pár příkladů typografie pomocí Emastic: http://www.allapis.com/emastic/typography.html a http://www.allapis.com/emastic/TypographyPulp.html

Na co myslíš, že se můžeme v technologii „CSS frameworků” ještě do budoucna těšit? Není to téma vyčerpané?

Éra CSS frameworků dokonce ještě nezačala. Dneska nikdo nepíše javascriptový kód, všichni užíváme nějaký framework typu jQuery, Moo …

Mnoho vývojářů a designérů bude milovat rychlá řešení za účelem rychlejšího vývoje a možnosti věnovat čas jiným problémům jako použitelnost a design.

Neříkám, že CSS frameworky jsou perfektním řešením pro každý problém, ale mohou vám pomoci vyvíjet rychleji bez práce na kompatibilitě mezi prohlížeči.

Je to zajímavé téma k diskuzi. Doufám, že mnoho ze čtenářů bude na WebExpo a tak můžeme v rozhovoru o budoucnosti CSS frameworků pokračovat.

Podle programu WebExpo máš na své přednášce docela dost zdánlivě ne až tak souvisejících témat – CSS frameworky, grid a zlatý řez. Na co přesně se můžeme těšit?

Skutečně se na přednášku na WebExpo těším. Zhodnotím nějaké výhody a nevýhody CSS frameworků, ale hlavně budu mluvit o tom, proč jsem se rozhodl vytvářet a jak jsem navrhoval některé ze svých 7 CSS knihoven. Také budu mluvit o designu založeném na gridu a o designu s ohledem na zlatý řez. Věřím, že si WebExpo všichni užijeme a navzájem se od sebe něco naučíme. :-)

Díky za rozhovor a budeme se těšit v Praze!

English original. Vladimirův blog.

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.

Typotheque … is working on a web font-embedding system which is based on W3C standards and provides a secure, reliable way to use fonts whose files are hosted on a global network of servers (cloud hosting).

Bude zřejmě využívat stávající podpory @font-face a on-the-fly konvertovat do EOT formátu pro MSIE:

Owners of Typotheque font licenses can create embeddable fonts via their Typotheque accounts. Simply enter the URL(s) where the font will be used and the languages to be supported, and our system instantly generates a short block of CSS code. Paste the code into your website, and you are ready to start using the font. You will not work with actual font files, but with the CSS code linking to the font files. For most browsers TTF subsets are used, for Internet Explorer, fonts are converted to EOT format on the fly.

Díky tomu dle vlastních slov bude podporovat 95 % prohlížečů.

Od písmolijny sympatický krok, který má však dvě úskalí

1. Využívat bude zřejmě jen jejich vlastní fonty (například Fedra), což komplikuje kombinace více fontů od více písmolijen.
2. Díky využití nativního @font-face zůstává problém s defaultním ne-vyhlazováním písma. Například ve Firefoxu nebo MSIE 6 na Windows XP příklady (1, 2) nevypadají nejlépe.

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?