V dnešním článku se blíže podíváme na nejčastější chyby, kterých se kodéři dopouštějí při tvorbě webu za pomocí kaskádových stylů. Tento jazyk je sice velmi mocný, na druhou stranu nijak neomezuje tvůrce webu v jeho používání, což vede k častým chybám. Přináším vám tedy soupis deseti nejčastějších chyb, které lze v CSS udělat.
- Optimalizace pro různé prohlížeče
Jedná se pravděpodobně o nejčastější problém, protože různé prohlížeče kód interpretují různě. V optimální situaci se vaše webová stránka zobrazí ve všech prohlížečích stejně, realita je však, jak už to tak bývá, někde jinde. Způsob, kterým jádra dvou nejrozšířenějších prohlížečů - Firefoxu a Internet Exploreru - renderují stránku, se v mnoha věcech liší, mnohdy tedy dostanete rozdílné výsledky. Situace se v průběhu let výrazně zlepšila, některé odlišnosti však přetrvaly. Někteří weboví vývojáři stránku optimalizují pouze pro svůj oblíbený prohlížeč, aniž by zkontrolovali výsledek i v konkurenčních programech. V mnoha případech nezpozorujete žádný rozdíl, v některých však může dojít k mnoha nechtěným situacím - od mírně posunutých prvků na stránce až k naprostému rozhození layoutu, ve kterém se poté uživatel či čtenář nemusí orientovat. K ověření správného zobrazení v nejrůznějších prohlížečích a na nejrůznějších platformách slouží výborný nástroj Browsershots. Tento nástroj je velmi jednoduchý - zadáte url vašich stránek, zvolíte, na kterých prohlížečích a platformách se mají otestovat, a do několika minut obdržíte výsledek ve formě snapshotů. Snadno tak zjistíte, ve kterých prohlížečích se vaše stránky zobrazují korektně, a ve kterých nikoliv.
- Optimalizace pro nízká rozlišení
Spousta vývojářů dnes vlastní displeje s vysokým rozlišením (a nutno dodat, že na to jsou patřičně hrdí) a nic je nenutí optimalizovat pro nižší rozlišení. Situace na druhé straně barikády je však jiná - najde se velké množství lidí, kteří web stále prohlížejí v nižších rozlišeních (800x600 či 1024x768), a pokud pro tato rozlišení není stránka optimalizována, může vám být sebelepší design k ničemu. Zastoupení různých rozlišení, která používají návštěvníci vašich stránek, lze celkem dobře odpozorovat z monitorovacích služeb jako je Toplist či Google Analytics. Pamatujte: pokud optimalizujete vaše stránky i pro nižší rozlišení, máte větší šanci, že téměř každý návštěvník najde informace, které hledá.
- Opomíjení frameworků
Pokud vytváříte layout pomocí CSS vlastními silami úplně od začátku, možná byste se sami měli zamyslet, proč tak činíte. Ani v oblasti CSS nic nového pod sluncem nevymyslíte. Existuje spousta frameworků pro snazší práci s CSS - například Blueprint Framework či 960 CSS Framework. Největší výhodou těchto pomocníků je, že nemusíte začínat od naprostého začátku, to již udělal někdo za vás. Jsou navíc dobře vyladěné pro správné zobrazování ve všech majoritních prohlížečích, odpadá tedy práce s testováním kompatibility. Pokud tedy nevyvíjíte projekt, ve kterém mají vaše kódy opravdové opodstatnění, použijte raději některý z CSS frameworků. Proč znovu vynalézat kolo?
- Generické třídy
Pokud chcete přemýšlet o dobré znovupoužitelnosti nějaké třídy, je vhodné, aby její název vypovídal o tom, co ona třída ve skutečnosti dělá. Mezi výhody tohoto postupu patří fakt, že nemusíte pro různé prvky na stránce vytvářet různé třídy, které v podstatě dělají to samé. Výstižný název třídy zajistí, že nebudete v budoucnu muset přemýšlet, co třída dělá. Ukážeme si to následujícím příkladě, kde je však kvůli bugu v prohlížeči kódů zdvojené slovo „right“ - správně má samozřejmě být .right{float:right}.
Pokud nyní chcete zarovnat prvek doprava, stačí mu přiřadit třídu „right“, která svým pojmenováním jasně vystihuje svoji podstatu..right{float:right}
Je vhodné použít nejméně tři generické třídy, a to:1.
.clear{clear:both} .right{float:right} .left{float:left}
- Nevalidní HTML
Pokud jste netušili, že nevalidní HTML kód může ovlivnit CSS, tak věřte, že může, a to dost dramaticky. Validaci stylu totiž můžete provést jen tehdy, pokud je validní i váš (x)html kód. Pokud máte pocit, že vaše styly nepracují tak, jak by měly, zkuste nejdříve zkontrolovat html. Neuzavřený div či sloupec tabulky může způsobit opravdovou paseku, je tedy třeba na to dávat pozor.
- Nevalidní CSS
Nezapomeňte validovat vaše soubory se styly - v případě problému dostanete dost jasné upozornění, v čem je zakopaný pes. Pokud je vaše CSS validní, máte mnohem větší šanci na kompatibilitu v různých prohlížečích.
- Přehnaně velké obrázky na pozadí
Hlavně začátečníci v oblasti webdesignu mají tendenci na pozadí „naplácnout“ nějakou velkou fotku, nejlépe ještě v bitmapovém formátu, a nestačí se potom divit, že se jim stránka načítá velmi, velmi pomalu. V mnoha případech lze tento problém vyřešit opakováním menšího obrázku pomocí vlastnosti background-repeat. Načteme tak mnohem méně dat, což urychlí načtení stránky. Někdy se samozřejmě velkým obrázkům na pozadí nevyhneme, musíme však počítat s vyšší prodlevou načtení stránky, než kdybychom použili malé obrázky či jednolitou barvu.
- Zbytečné CSS
Často zapomínáme na jednu základní věc - CSS by nám mělo práci usnadnit a tedy i urychlit. Někdy je prostě jednodušší použít tabulku, než vymýšlet layout s plovoucími divy. Není vždy nutné používat pouze jednu technologii na úkor druhé, pokud nám druhá dokáže dát totéž a efektivněji.
- Inline CSS
Inline zápis CSS je sice legální záležitost, avšak jeho použití je spíše nedoporučováno. Základní premisou CSS je udržovat odděleně html kód a styly, což si s inline zápisem navzájem odporuje. Pokud budete sdružovat styly do jednoho souboru, budete mít vždy všechny třídy pěkně po ruce a nebudete muset procházet html kód a následně z něj „dolovat“ inline zapsané CSS.
Místo tohoto zápisu
proto raději použijte tento:1. text
1. text
- Příliš mnoho souborů
Viděli jste někdy design, který byl rozdělen na dvanáct CSS souborů? Editování byť malé změny v takovém kvantu souborů se velmi rychle může stát noční můrou, nemluvě o času, který prohlížeč potřebuje k jejich načtení. Optimální je používat jeden až dva soubory, s více soubory už můžete mít velké problémy.
Původním autorem tohoto článku je Glen Stansberry, jedná se o překlad.