SUIT CSS versus BEM

Metodik organizace CSS existuje více. Mezi ty nejznámější patří OOCSS (Object-Oriented CSS) od Nicole Sullivan, SMACSS (Scalable and Modular Architecture for CSS) Jonathana Snooka nebo v minulých letech hojně diskutovaný Atomic Design od Brada Frosta. Ačkoli principy některých metodik využívá v organizaci kódu svých projektů většina z nás, třebaže to ani netušíme a došli jsme k nim s přibývajícími zkušenostmi sami, nejpopulárnější metodikou je určitě BEM. BEM je natolik populární, že o jeho existenci často vědí i vývojáři nebo designeři. Čím to?

OOCSS a SMACSS jsou především souhrnem principů, jak psát kód, který je znovupoužitelný, výkonný a dlouhodobě dobře spravovatelný. Není snadné popsat je v jediné větě — know-how SMACSS je věnována celá kniha, stejně tak Atomic Design má svůj e-book (který je ale dostupný také zdarma on-line).

Blok, element, modifikátor

BEM je jiný. Obsáhlé traktáty nechává stranou a jde přímo k věci. Genialita BEMu spočívá v terminologii. Ta je jednoznačně rozpoznatelná a uchopitelná pro široké spektrum lidí.

.block__element--modifier

Metodika BEM vznikla před lety v ruském Yandexu. Je úžasně funkčním nástrojem pro organizaci komponentově stavěného CSS kódu. Říká, že styly komponent je možné zařadit do jedné ze tří kategorií:

• blok
• element
• modifikátor

Klíč k úspěchu

I atomický design staví svůj úspěch na terminologii. Jeho atomy, molekuly a organismy se také zdají být snadno pochopitelné, uvedení této architektury v praxi už ale tak jednoduché není. Struktura může nezkušenému vývojáři rychle přerůst přes hlavu. To, co by na první pohled označil jako atom, může být při nekorigovaném užití terminologie velmi snadno organismem. Termíny mu tak mohou dojít rychleji, než by čekal. Postup kompozice v atomickém designu není čitelný čistě z terminologie. Možná i proto o něm Brad Frost napsal celou knihu.

O atomickém designu ale jindy. Než se pustíme do srovnání dvou vybraných metodik, je třeba být fér a říci, že OOCSS, SMACSS, Atomic Design, BEM a SUIT CSS nejsou souřadné termíny. Zatímco první tři jmenované jsou architektury pro organizaci celého CSS v komponentovém projektu, BEM a SUIT CSS jsou „pouze“ metodikou pro udržitelné pojmenování CSS tříd. Samy o sobě nebudou fungovat, klíčem k úspěchu je použít je ve spojení s komponentovou architekturou.

Problém BEMu

Jestliže v atomickém designu může terminologie snadno přerůst přes hlavu, uživatelé BEMu často trpí podobným problémem. BEM totiž vybízí k neomezenému zanořování. Co to znamená? Ačkoli v oficiální dokumentaci o zanořování není zmínka, nějak si přihodilo, že typické pojmenování tříd v reálném projektu se může rychle zvrtnout. Začít můžeme třeba takto:

.search {}
.search__input {}
.search__button {}

Což je úplně v pořádku. Často se stane něco takového:

.search {}
.search__form {}
.search__form__input {}
.search__form__button {}

Stále v mezích? Co ale takto:

.search__form__button__icon {}

Čtvrtá úroveň zanoření už bije do očí. Je opravdu nutná? Co udělat jinak? Co když budu potřebovat zacílit na pátou úroveň? Co když — a to především — budu třídu ikony potřebovat použít jinde v komponentě a ne pouze v tlačítku, jak vyplývá z jejího názvu? Pozdější reorganizace komponenty bude složitější. A kolik úrovní zanoření je vlastně v pořádku?

Přestože se tento nešvar vyskytuje ve spojení s BEMem, díváme se na nevhodné užití metodiky, nikoli na kód dle metodiky, která by sama o sobě byla nevhodně navržená. Největší problém BEMu je tedy v uživatelích, nikoli v metodice samotné.

Co tedy s tím? Komponentově smýšlející kodér by se již u druhého zanoření měl zastavit a rozpoznat znak přerostlé komponenty, kterou je vhodné rozdělit na menší:

/* search.css */
.search {}
.search__form {}

/* input.css */
.input {}

/* button.css */
.button {}

/* icon.css */
.icon {}

Nebo může stačit netrvat na vícenásobném zanoření:

/* search.css */
.search {}
.search__form {}
.search__input {}
.search__button {}
.search__icon {}

Větší flexibilita v rámci komponenty je zřejmá, zároveň zůstalo zachované i kýžené zapouzdření uvnitř komponenty. K hypotetické ukázce neznáme design, bylo by třeba rozhodnout se podle konkrétní situace, který postup bude vhodnější.

Skrytá závislost

Ukázali jsme si, že příčina největšího strašáka v BEMu vězí mezi klávesnicí a židlí. BEM však má ještě jiný problém: stavové třídy.

Podle dokumentace se třídy označující stav komponenty zapisují syntakticky stejně jako modifikátory:

.block--state-active {}

Rozdíl je jen v prefixu state. V CSS může takový detail vypadat docela nevinně. Z pohledu stylů není mezi modifikací a stavem žádný rozdíl, vždyť jde jen o variaci vzhledu komponenty. Stavy se však — na rozdíl od modifikací — využívají pro javascriptovou funkcionalitu. Zahrnutím názvu komponenty do pojmenování stavové třídy tak vznikne mezi CSS a JavaScriptem závislost, která má jednu zásadní vadu: není vidět.

JavaScript v projektu leží stranou od CSS kódu. A často nad ním drží ochrannou ruku jiné lidé než kodéři. Když se z jakéhokoli důvodu přejmenuje CSS třída, na niž je navázána javascriptová funkcionalita, musí se stejně tak změnit název i v JavaScriptu, který by jinak rázem přestal fungovat.

Vlastní inicializace skriptů je již vyřešená záležitost: místo komponentových CSS tříd se JavaScript navěšuje na data atributy nebo na CSS třídy s prefixem js, např. js-navigation. Při úpravách v HTML je tak na první pohled zřejmé, že se taková třída váže k interaktivitě (zároveň je zapovězeno ji jakkoli stylovat) a není radno ji jen tak zahodit či přesunout na jiný HTML prvek, aniž bychom věnovali pozornost také JavaScriptu. Pro stavové třídy však BEM nic takového nenabízí:

$(".js-navigation").addClass("navigation--state-open")

Tady jsme s BEMem skutečně v koncích.

SUIT CSS

Nicolas Gallagher má na kontě jeden projekt, na němž stojí základy množství webů po celém světě. normalize.css je malý, ale šikovný stylopis, který sjednocuje (normalizuje) odlišnosti ve výchozím vykreslování prohlížečů a i v době moderních prohlížečů má stále své místo. Kromě toho stojí také za metodikou SUIT CSS. To je celá sada nástrojů pro frontendový vývoj včetně základních CSS souborů a vlastního preprocesoru postaveného kolem PostCSS. Do nástrojů si ale nenecháme mluvit a zaměříme se na teoretickou část balíčku, a to konvenci pojmenovávání.

Podobně jako BEM ani SUIT CSS nechodí kolem horké kaše a udává jasné pokyny k pojmenování:

.u-utilityName {}
.ComponentName {}
.ComponentName--modifierName {}
.ComponentName-descendentName {}
.ComponentName.is-stateOfComponent {}

Rovnou v základu tedy řeší:

• utility třídy (odsazení, zvýraznění textu apod.) — bonus oproti BEMu
• bloky
• modifikátory
• elementy bloků
• stavy komponent — odpověď na druhý nejvýznamnější problém BEMu

V podrobné dokumentaci se dále věnuje pojmenování elementů — vnořených prvků. Zanořování v názvech CSS tříd SUIT CSS výslovně nezakazuje, ve všech ukázkách ale vícenásobné zanoření neřeší a přímou podřízenost komponentě (bloku) považuje za dostačující:

<article class="Tweet">
  <header class="Tweet-header">
    <img class="Tweet-avatar" src="{{src}}" alt="{{alt}}">
    …
  </header>
  <div class="Tweet-bodyText">
    …
  </div>
</article>

Co na to BEM

Pokud máte BEM rádi, zvykli jste si na něj (i na jeho svérázné oddělovače) a máte v něm napsaný celý projekt, není důvod přecházet na SUIT CSS. Dokonce ani u nových projektů nemusíte vystupovat ze zajetých kolejí.

Harry Roberts vzal již před lety BEM do vlastních rukou, když si uvědomil jeho omezení. Pod zkratkou BEMIT (BEM + ITCSS) přišel s rozšířením syntaxe BEMu o prefixy (namespace; např. o-media pro objekty, c-button pro komponenty a u-offset pro utility), které má SUIT CSS již v základu (byť schované hlouběji v dokumentaci), responzivní přípony ( o-media@md) a navrch přidal ještě sadu stylů pro ladění CSS v průběhu vývoje. Jedině konvenci pro stavové třídy si musíme doplnit sami.

BEM není třeba házet do žita. Je to skvělá konvence pro pojmenování v CSS, která nezískala na popularitě bez příčiny. Díky geniální jednoduchosti je její uchopení snadné i pro začátečníka. A pokud BEM rozšíříme o konvence ze SUIT CSS, nejsou žádné překážky, které by nám bránily BEM používat dál. Pro nové projekty a zvykem nezatížené vývojáře je však SUIT CSS více než zajímavá volba, která předchází problémům základní specifikace BEMu a vede k psaní čistého, dobře strukturovaného komponentového CSS.

Související odkazy

• BEMIT: Taking the BEM Naming Convention a Step Further (Harry Roberts)
• MindBEMding – getting your head ’round BEM syntax (Harry Roberts)