Vzhůru dolů

Jak v Internet Exploreru zjistit, zda prvek má hasLayout?

javascript:alert(id_hledaneho_prvku.currentStyle.hasLayout);

Občas se může zdát, že MSIE bug, který právě proklínáte, nemůže ze špatného nastavení vlastnosti hasLayout vycházet, protože ji má určitě nastavenou správně. Ověřte to vždycky raději tímhle způsobem v adresním poli prohlížeč, nejspíš se totiž mýlíte. Vím o čem mluvím. .-)

Manuál stylopisů (a jednoduchost CSS můžeme zase chválit)

Jak se ve změti CSS pravidel webového projektu dobrat systému, který bude snadno přenositelný na jiného člověka? Jak to udělat s technologií, jejíž esencí je jednoduchost? Supergeeky proklínaná a amatéry zbožňovaná vlastnost kaskádových stylů.

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.

Otcovsky o organizaci času

Toto je skutečný příběh. :-)

Jedna z věcí, o které mě narození syna obohatilo, je zvýšená ostražitost k neúčelnému trávení vlastního času. Ne tak jak se to říká v knížkách nebo školeních GTD, myslím doopravdy. Jako rodiče mě Honzík vybavil kruhy pod očima a výborným čichem na infiltraci blbostí do času stráveného prací.

Spousta lidí má proti blbostem dobrý imunitní systém. Jenže hlavní hygienik je proti prasečí chřipce odolnější než já proti nesmyslné práci. Důvodům proč ji dělat říkám vnitřně pragmatizmus nebo taky služba vyšším cílům. To se pak dobře zdůvodní blbosti jako:

1. čtyři roky spravovat web s cizím strašidelným uživatelským rozhraním a stejně strašným technickým zpracováním —— protože se mi jednou určitě klienta podaří přesvědčit, že investice do rozhraní je potřebná a projekt se rázem stane zajímavým
2. rychle vyšvihnout malý prezentační web, na kterém naprosto nehrozí, že bych se něco naučil —— protože je to pro člověka/instituci, které mám rád a pomůžu jim tím
3. dvakrát týdně ručně aktualizovat statické HTML stránky různých webů —— protože to zabere chvilku a nestojí za to vymýšlet jak to udělat efektivněji

Pár dní v měsíci takovou práci dělám. Jsem z toho pak trochu otrávený. V nejhorším si vnitřně vynadám, že to je naposledy a zajdu si zaplavat. Zase bude dobře a za měsíc takovou práci vezmu znova.

Pak si znova řeknu, že jsem kůň a v nejhorším si zajdu zaplavat.

Jenže když jsem uprostřed blbé práce a odvedle se ozve synek, to už si nestačí vynadat a večer na bazén. Na protilehlé misce vah není jen můj ztracený čas, ale taky čas, který jsem mohl věnovat jemu. Ono přebalování bývá výrazně smysluplnější než HTML značky sedm let starého webu.

A pak zjistím, že…

1. klienta se špatným přístupem k uživatelskému rozhraní nemůžu nikdy přesvědčit, protože mu to takhle bude vyhovovat navěky
2. malý prezentační web budu díky nezáživnosti „vyšvihávat“ pomalu, příteli nepomůžu a projekt skončí oboustrannou frustrací
3. aktualizaci statického obsahu si nakonec klient rád zrealizuje sám, a mě bude bavit vymýšlet způsob jakým to bude dělat

A tak jako v jiných, i v tomto skutečném příběhu stojí za to opakovat i ta největší klišé: Jediný důvod proč něco dělat, je ten, že nás to baví. Nemusíme dělat cokoliv jiného. Z žádného důvodu.

Cufón nebo Typeface.js — který vybrat?

Než budeme moci v prohlížečích začít široce používat @font-face, Typekit a další písně typografické budoucnosti, musíme se rozhodnout mezi třemi hlavními technologiemi sloužícími k nahrazení písma přímo v prohlížeči. sIFR, Cufón a nebo Typeface.js.

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.