Vývoj efektivity zápisu CSS

Jak efektivně nastylovat webové stránky a jak tvořit CSS tak, aby to dávalo smysl? Na tuto otázku samozřejmě neexistuje jednoduchá odpověď. Metod a oblastí je mnoho a vždy je nutné přistoupit k dílčímu problému s konkrétním řešením. V tomto článku najdete velmi stručný přehled vývoje, popis nejčastějších problémů a nástup technik, které mají za úkol tyto problémy řešit.

Trocha historie

V roce 1994 přišel Håkon Wium Lie na to, že je potřeba vytvořit jazyk, který bude vytvářet možnosti, jak vizuálně upravovat dokumenty na webu. Hlavní myšlenka byla postavena na tom, že je potřeba oddělit obsah od prezentace. Stalo se tak to, že se spolu s dalšími autory podíleli na vytvoření první verze CSS, které postupem času implementovaly všechny prohlížeče, a po HTML se z CSS se stal druhý standardizovaný jazyk pro W3.

Tato archivní e-mailová komunikace ukazuje počátky vzniku myšlenky vizuálních úprav HTML dokumentů. Jak je vidět, po vložení stejného HTML se na dvou různých prohlížečích (Netscape a Mosaic) zobrazoval obsah rozdílně. Vývojáři prohlížeče Mosaic se totiž rozhodli přidat před seznam (dnes známý jako unordered list) odsazení seshora. Prostě si mysleli, že to tak bude prostě vypadat lépe. Všichni to pak vnímali jako bug a získávali potřebu mít kontrolu nad tím, jak se jejich obsah na webu zobrazí.

V polovině 90. let, kdy se začaly objevovat první webové stránky, bylo odlišení od výchozího nastavení zobrazení v prohlížečích opravdovým oříškem. V době, kdy se kaskádové styly teprve testovaly byla možnost upravovat design jedině pomocí HTML atributů. První webové prohlížeče jako ViolaWWW však neumožňovaly upravit vizuální podobu takřka vůbec.

Co bylo před tím, než přišlo CSS?

Postupem času začali autoři webových stránek tvořit první pokusy o to, čemu dnes říkáme webdesign. Častým příkladem stránky z 90. let je stránka Space Jam. Stránka slavného animovaného filmu od WarnerBros je stále i po 24 letech online v původním stavu a tak je možné si ji projít a prozkoumat.

Na tomto webu je dobře vidět, jak se v této éře přistupovalo k barevnému odlišení textů a odkazů a jak se pracovalo s layoutem.

Veškeré barvy jsou definovány v těle stránky, kde tvůrci pomocí atributů HTML nastavili základní pravidla pro zobrazení. Konkrétně pak atributy bgcolor, text, link, vlink a alink. Takto definované atributy pak umožnily odlišně zobrazit barvy textů, odkazů a pozadí.

Dalším pěkným příkladem na tomto webu je layout . Ten se ve své době upravoval jen pomocí tabulek, a struktura layoutu se tak navrhovala pomocí jedné či více zanořených tabulek do sebe. Tato technika se pak několik dalších let používala pro tvorbu všech layoutů webových dokumentů. Nejprve pro v té době populární kruhový layout (příklad webu Space Jam) a následně pak Holy Grail Layout, který byl trendem ve webdesignu spoustu let. Tato tabulková technika se pak doporučuje dodnes pro tvorbu newsletterů a PDF generovaných pomocí HTML, protože mnoho e-mailových klientů se prostě nerozhodlo změnit své systémy.

Code newsletters like it’s still 1999

Na tomto příkladu je vidět, jak přišli autoři k výsledku tohoto kruhového layoutu, který byl v té době populární. Tím se chtěli společnosti odlišit od konkurence, a vznikaly tak první pokusy o vizuální změny výchozího nastavení.

Umístění obrázků do kruhového layoutu je pak řešeno opět pomocí atributů tabulek — konkrétně pak align a valign a taky pomocí HTML tagů <br>.

Tímto způsobem se několik let (progresivnější vývojáři, kteří experimentovali s CSS jen prvních pár let) tvořil webdesign.

Nástup CSS

Nástup kaskádových stylů byl v té době revoluční. Eric Meyer — který se spojil s ostatními — začal v roce 1998 popisovat, jak je možné implementovat a používat kaskádové styly. Postupem času se tak CSS dostalo na první webové stránky a začalo se plně využívat pro designování webových stránek. Třeba tímto způsobem.

Následně pak přicházely další deklarace, vlastnosti nebo hodnoty, a CSS se tak stalo dalším nepostradatelným jazykem pro vývoj webů.

Na začátku to byla velká revoluce. Už nebylo potřeba pro změnu barvy nadpisu přepisovat hodnoty atributů na všech stránkách, ale stačila jedna drobná změna v kaskádových stylech — wohoo! Co víc si přát.

Vývojáři začali CSS používat, ale nikdo se nezabýval potřebou styly nějak strukturálně organizovat a udržovat. Psaní CSS bez jakékoli organizace nebo myšlenky pro udržitelnost už nebylo dostačující. Neexistovaly žádné postupy, jak udržovat kaskádové styly a jak se vyrovnat s mnohdy nekonzistentním designem velkých webů (což trvá v některých případech dodnes). Začaly tak vznikat komplikace.

”Two CSS properties walk into a bar.

A barstool in a completely different bar falls over.

Problémy s CSS

Jaké komplikace můžou vznikat při psaní CSS? Hlavně pro začátečníky může být psaní stylů těžkým oříškem. Na jednu stranu jsou kaskádové styly díky své přímočarosti velmi jednoduché na pochopení, na druhou stranu je pak dost komplikované styly udržovat, upravovat a strukturovat. Problémů se může objevit mnoho. Zkusím tak některé z nich stručně popsat.

Hluboké zanořování selektorů a vysoká specificita

S tímto problémem se určitě setkal každý, kdo alespoň někdy s CSS pracoval.

Vývojář dostane zadání od grafika, promyslí, jaký HTML element by se dal použít, a pustí se do zapsání selektoru. Rozhodne se použít unordered list, ze kterého chce vytvořit seznam s modrými barvy odkazů a velikostí písma 20px. Pro výběr použije selektor „seznam”.

HTML tak vloží na web — hluboko do struktury webu, kam patří a kde se má zobrazit.

Zapíše pak následující CSS:

Oops? Barva odkazů je červená, písmo je velikosti 16px a navíc tučně. Podívá se do DevTools a zjistí, že je selektor už přetížen nějakým jiným selektorem, který brání ve vykreslení správného výsledku:

Jakou má teď vývojář možnost? Nezbývá nic jiného, než zvýšit specificitu nově vytvořeného selektoru, upravit přetěžující selektor a nebo použít !important. Možností je samozřejmě víc, ale principiálně jde stejně pořád o boj se specificitou.

Praxe je v drtivé většině taková, že se do úprav již hotového selektoru málokdo pustí a !important víme, proč nepoužívat. Proto nezbývá jiná možnost než zvýšit specificitu přidáním třídy “seznam” k našemu unordered listu.

Vzniká tak nový element, který se nedá nijak dál použít a je odsouzen k tomu, aby zůstal jen tam, kde je. Pokud bude potřeba použití jinde, nezbývá než přidat další kus kódu.

Závorkové peklo alias „Nesting hell”

Většina vývojářů si málokdy uvědomuje, že psaním CSS zapisujeme design webových dokumentů a aplikací. S nástupem popularity preprocesorů se tak psaní kaskádových stylů kousek přiblížilo programovacím jazykům (díky možnosti používat proměnné, cykly nebo např. mixiny). Preprocesory přišly taky s jednou novinkou, a tou bylo zanořování selektorů do sebe.

Rozluštění takového kódu a jeho následná úprava tak byla v některých případech takřka nemožná. Následující kód vypadá hrozivě, není to však vůbec nic výjimečného a při refaktorování CSS se s něčím takovým setkáme docela často.

Jak asi bude vypadat výsledný zkompilovaný selektor? Netroufl jsem si zveřejnit výsledek tohoto selektoru, ale z následujícího obrázku si můžete vytvořit představu, jak takové výstupy vypadají.

Takového zanořování selektorů bychom se měli vyvarovat a nedopustit, aby se v souboru preprocesoru ani ve výsledném CSS takový kód objevil. Dobrým zvykem je tak používat zanoření selektorů maximálně do druhé nebo s výjimkou do třetí úrovně. Potom je kód dobře čitelný a nezpůsobí nám nikdy nekončící bolesti hlavy.

Takový zápis se pak dobře čte a vývojář hned pochopí, co se děje a jak může dál zápis rozšiřovat a jak s ním pracovat. Dobře tuto problematiku popsal Martin Michálek na svém webu.

Kaskáda — pořadí zápisu pravidel a struktura souborů

Na pořadí záleží. Dalším typickou chybou při psaní CSS je ignorování faktu, že musíme dbát na to, v jakém pořadí selektory zapisujeme. Tato vlastnost CSS odrazuje mnoho vývojářů v tom, aby se psaním stylů zabývalo a dál rozvíjelo, protože jednoduše nemají pochopení pro tyto vlastnosti a nedokážou se s ní vypořádat.

Stručně ale výstižně tuto problematiku opět dobře popsal Martin Michálek na svém webu Vzhůrudolů.

Metodologie a architektury CSS

Za účelem řešení vlastní složitosti CSS byly zavedeny různé druhy osvědčených postupů a technik, které nám pomáhají vytvářet smysluplný, udržitelný a rozšiřitelný kód pro design našich webů a aplikací.

Pro většinu potřeb ve webovém designu existuje více než jeden způsob přístupu k danému problému. Existují čtyři metody, které vynikají mezi ostatními při zvažování, jak strukturovat kód a pojmenovávat třídy.

OOCSS

V roce 2008 si Nicole Sullivan vypůjčila koncept objektově orientovaného designu za účelem poskytnutí struktury do CSS. Na přednášce Web Directions North představila svůj koncept OOCSS.

Stručně řečeno — tato metodika definuje CSS objekt jako vizuální vzor, který je možné použít na celém webu. Má za úkol směřovat naše myšlení při návrzích na znovupoužitelný kód, který je lépe editovatelný a udržitelný.

OOCSS má několik pravidel, které je nutné následovat. Základem této metodiky jsou ale dvě pravidla:

1) Oddělení vzhledu a struktury
Znamená to, že nikdy nedáváme do selektorů HTML elementy. V případě změny se pak musí upravovat kód na dvou místech. Takže místo:

bychom ke kódu měli přistupovat následně a nevytvářet závislosti na HTML:

2) Oddělení obsahu a kontejneru:
Toto pravidlo říká, že bychom měli zapisovat selektory nezávisle na umístění na stránce, aby byly co nejlépe použitelné napříč webovým dokumentem. Vlastně nám říká, že se mám jednoduše vyhnout následujícím selektorům:

SMACSS

Scalable and Modular Architecture for CSS je metodologie a stejnojmenná kniha od Jonathana Snooka. Hlavní myšlenkou SMACSS je kategorizace systému pravidel CSS.

1. Base
Do této kategorie patří základní nastavení pravidel HTML elementů. Patří sem normalizace a základní nastavení.

2. Layout
Do této vrstvy patří dimenzionální deklarace.

3. Module
Vrstva pro to, čemu říkáme znovupoužitelné komponenty. Zde by měly být všechny deklarace tlačítek, sidebarů, menu apod.

4. State
Sem patří deklarace námi předem definovaných pravidel rozšířených o stavy. Jedná se o závislosti na JavaScriptu.

5. Theme
Tato vrstva je nepovinná a patří do samostatného souboru. Jedná se o seznam pravidel, které mění vizuální podobu, pokud chceme vytvořit jinou identitu naší aplikace.

BEM

BEM je metodologie pro psaní CSS, za kterou stojí vývojáři z ruské korporace na internetové služby. BEM znamená Block Element Modifier, který shrnuje použitou konvenci pojmenování a celkový přístup k organizaci.

Hlavním přínosem této pojmenovávací konvence je to, že se vytváří selektory nejnižší specifičnosti a díky jedinečnosti pojmenování tak nevznikají žádné konflikty. BEM je také užitečný pro práci ve větším týmu vývojářů, protože je jeho struktura jednoduchá a dá se rychle pochopit.

Podrobněji tuto problematiku popsal (ano, opět) Martin Michálek na svém blogu Vzhůrudolů, který se zabývá webovými technologiemi a frontendem obecně.

ITCSS

ITCSS neboli Inverted Triangle CSS je architektura (nebo metodologie udržování organizace jednotlivých CSS souborů) od Harryho Robertse, která nám pomáhá organizovat naše CSS soubory podle určitých pravidel. Díky ní docílíme správnému zařazení a dovolí nám tak psát smysluplné a dlouhodobě udržitelné styly.

Tato organizace stylů se nejvíce hodí pro práce na větších projektech a taky pro fungování v týmu, kde do CSS zapisuje více vývojářů. Samotná struktura se neobejde bez dalších principů a metodologií, ale jako základ pro dobrou údržbu našich souborů je výborná. Využití této architektury ale funguje i na těch nejmenších projektech a dává smysl ji využívat všude.

Základní myšlenka spočívá v řazení našich selektorů podle specificity, se kterou méně zkušení vývojáři často zápasí. Struktura je rozdělena do 7 kategorií podle specificity a je možné ji rozšiřovat a modifikovat podle potřeb.

Základní rozdělení v projektu pak může vypadat následovně:

  1. Settings
    Prostor pro preprocesory — nastavení proměnných jako např. barvy, design tokeny, typografie, gridu.
  2. Tools
    Vrstva s mixiny, funkcemi, media queries.
  3. Generic
    Zde vkládáme styly pro knihovny třetích stran jako normalize, reset, definice box-sizing.
  4. Elements:
    Selektory pro holé HTML elementy jako <h1>, <p>, <article>, <a>.
  5. Objects
    Definice tříd pro layout, mřížku, odsazení — znovupoužitelné nedekorativní styly.
  6. Components
    Specifické komponenty napříč projektem — accordion, buttons, breadcrumbs, tooltip.
  7. Trumps (Utilities)
    Utility třídy, které mají za úkol ovlivnit jednu konkrétní vlastnost CSS a jsou ve většině případů zapisovány s nejvyšší důležitostí.

Systém používání této metodiky je mnohem důkladnější a před jeho použitím doporučuji jeho nastudování. Mnozí tuto organizační strukturu chápou nepřesně a přijdou tak o obrovské výhody, které nám ITCSS nabízí. V češtině to výborně a pečlivě rozepsal Adam Kudrna na blogu Frontend Garden.

JavaScript a CSS

Jak se s těmito problémy perou progresivní přístupy psaní stylů v JavaScriptových aplikacích jako CSS Modules, JSS nebo styled-components? To je téma na samostatné články a není mým cílem je tady všechny zmínit a popsat. Přichází však doba, kdy se díky dobré práci komunity okolo JavaScriptu rodí nové přístupy, které můžou v určitých případech dávat velký smysl v použití.

Závěrem

CSS má za sebou dlouhý vývoj a díky neustálému vylepšovaní (na kterém pracují ti nejzkušenější v oboru) se daří vylepšovat a rozvíjet jeho funkcionality a možnosti. Drží si tak stabilní místo vedle svých kolegů pro vývoj webových dokumentů a aplikací.

Pomocí správných metodologií, architektur a dobré znalosti jazyka můžeme vytvářet strukturované zápisy, které je snadné psát, udržovat a rozšiřovat.

Written by

Front-End UI/Design Developer — Deeply interested in CSS, webdesign and innovating page layout. A few words about me: www.ondrejkonecny.cz

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store