Hledá se vhodná třída. Zn.: Spěchá!
Čím rozsáhlejší web, tím více CSS tříd. **Některé jejich názvy mám už za léta používání zažité** a jsou myslím jasně srozumitelné i pro nezávislého „čtenáře“ mých stylopisů, například container, content nebo sidebar. Podle složitosti grafického návrhu případně doplněné o ocásek typu -inner, -wrapper…
Ale co s dalšími a dalšími třídami, které u rozsáhlých projektů přibývají s každým zpracovaným grafickým návrhem? V některých situacích už mi dochází fantazie, když musím **horko těžko vypotit další název třídy**. Podle grafického návrhu je většinou jasné, jakou bude stylovaný element plnit funkci, ale co s podobnými nebo třeba jen lehce změněnými elementy?
Hrušky a Jablka kontra Ovoce
Jako názorný příklad si vezměte tabulku obsahující hrušky. Dostane class="hrusky", nějaké ty styly a hotovo, odjezd. Jenže ejhle, v dalším návrhu je tabulka, která vypadá úplně stejně jako předcházející s hruškami, ale obsahuje jablka. Co s tím? Nechat nelogický název třídy, nebo přepsat na class="jablka"?
Nejlepší by bylo dát oběma tabulkám class="ovoce". Co když to ale z nějakého důvodu (šablona už je nasazená v aplikaci, muselo by se to přepisovat na X místech) nejde? Možná si také říkáte „Hloupý kodér, který nemyslí dopředu“, ale…
Za kolik rohů má kodér nahlížet?
Dobrý kodér by měl určitě za nějaký ten roh dopředu vidět, ale „vocaď pocaď“. Určitě by neměl jen tupě otevřít první péesdéčko a odshora dolů nakódovat. Osobně se mi osvědčilo si nejdříve opravdu důkladně **prohlédnout drátové modely i grafické návrhy a zamyslet se nad nimi**. Chvíle rozjímání nad návrhy, než člověk otevře editor, se mi potom při kódování několikanásobně vrátí.
Ale přeci jen jsem placený za kódování, nikoli za rozjímání, takže někde musí být hranice, kdy musím svoje „co kdyby“ rázně utnout a začít kódovat. **Od jistého okamžiku už je cokdybování kontraproduktivní.** Lehko si s ním vykonstruuji situace, které nikdy nenastanou.
Vrátím-li se tedy k výše uvedenému hruškovému příkladu, pak tedy ano – mohl jsem vědět dopředu, že se může vyskytnout i tabulka s jablky a pojmenovat třídu obecněji. Ale co kdyby se jednou v tabulce objevily třeba okurky? Bramborové knedlíky? Vzducholodě? Vycházkové hole asi takhle dlouhé?
Myslím, že někde u okurek je dobré rozjímání skončit a pojmenovat třídu potraviny, byť by se to v budoucnu mohlo ukázat jako špatné rozhodnutí.
Ono nahlížení za roh se netýká jen takových triviálních věcí, jako jsou názvy tříd. Jsou tu i úvahy typu „A co by se asi stalo, kdyby ten nadpis byl delší než v návrhu?“ nebo „Co když tam **nebude** tenhle box?“ nebo „Co když tam **bude** nějaký box navíc?“
A co vy?
**Máte pod kůží nějaké pojmenovávací konvence?** Jaké názvy tříd používáte? Můžete (musíte) si je vymýšlet sami, nebo vaše firma v coding standards myslela i na HTML a CSS? **Za kolik rohů nahlížíte?** Budu rád za vaše komentáře!
Václav Vracovský
HTML a CSS kodér ve společnosti Medio Interactive. Samouk, který se přes šablony pro živnostníky prokódoval až k největším rybám českého internetového rybníka.
vracovsky@medio.cz
Komentáře k článku
[1] Vlastimil Fišer | 10. 8. 2011 v 16.12
Určitě dobré téma na zamyšlení.
Já používám již dlouho zavedený styl, rozdělím si web na několik základních částí (minimálně header, content, footer) a poté vždy pojmenovávám třídy podle těchto částí, např.: .content_title, .fotter_link .. atd.
Ať se daří !
Vlasta Fišer
[2] ramino | 10. 8. 2011 v 16.53
S touto myslienkou som sa pohraval aj ja, ale nikdy som nenasiel konecne riesenie…hlavne elementy su jasne…vnorene odvijam od rodica napr. header-top, header-right, header-left,… potom som presiel na skracovanie h-top -> ht-left, ale pri vacsich weboch som sa uz stracal preto som sa upustil od skracovania.
A tabulky a buttony oznacujem farbou, tzn. farba ktora v tabulke prevlada pouzijem ako nazov triedy.
Vyrazne ulahcuje vymyslanie novych tried aj lesscss.
[3] Vašek Chromický | 10. 8. 2011 v 17.00
Dělám to podobně, jen jako oddělovník mezi těmito hypotetickými prefixy/namespacy používám pomlčku. Dá se to hezky štosovat do aleluja a ani třídy jako „content-form-item-errorList“ se pak člověk nezalekne. Navíc můžu mít v projektu třeba tisíc „…-errorList“ tříd, ale nebudou se mezi sebou bít.
U CSSek si myslím, že je nejdůležitější mít v nich pořádek — mít oddělená (mít jasno v tom, co jsou) pravidla pro layout, pro obsah, pro jednotlivé stránky atd., aby se v nich člověk neztratil. Společně se zmíněným pomlčkováním se to pak dá přežít :-).
Je to takový hodně zvláštní svět sám pro sebe. A s preprocesory je to všecko zas úplně jinak…
[4] Petr Staníček | 10. 8. 2011 v 17.55
Když tak nad tím přemýšlím, snažím se v HTML kódu držet věci co nejjednodušší a všechnu složitost a hierarchii přenést na bedra CSS.
Jinými slovy: místo poměrně jednoúčelové class=“col-left-list-item-selected“ mám jen vnořené třídy col-left, list, item a selected a všechna hierarchie je v CSS. Nebojím se používat opravdu mohutné kontextové selektory typu:
body.stories#content.col-left.list.item.selected { … }
Hodně tomu pomáhá řegba LESS framework, kde jsou podporovány vnořené definice a tohle se spravuje skutečně krásně a snadno. Jde jen o to, dobře si rozmyslet, co můžu na jaké úrovni nadefinovat obecné, co společné/sdílené a co účelové pro konkrétní kontext; co je vhodné nechat otevřené a nadefinovat až na dolní úrovni, a co předdefinovat už na obecnější úrovni a pak případně přepsat na spodku kaskády. Obvykle to praktikuju tak, že pokud nějaký prvek nebo třídu definuju v CSS už na nejvyšší úrovni, bez kontextu, pak je to univerzální, obecně platné, používané všude jednotně (jednotný styl pro A, H4, P.indent apod.), jinak všechno definuju až v konkrétním kontextu. A klidně i duplicitně, pokud je to ve prospěch přehlednosti a udržovatelnosti stylopisu.
Takže stručně shrnuto: co možná se netrápím složitými názvy tříd, třídy klidně recykluju přes různé kontexty – a v CSS pak minimalizuju obecné definice a dávám přednost přeně cíleným kontextovým selektorům. A rozhodně doporučuju všem popřemýšlet o LESS a podobným nadstavbám.
[5] SEO Konzultant | 10. 8. 2011 v 18.01
Osobně se snažím popisovat co nejobecněji a spíš významem než obsahem. Tj. např. pro tabulku libovolných produktů či služeb bych použil „products“ a samozřejmě násobnou třídu „products jablka“, pakliže bych to měl na webu nějak diferencovat. Případně jestli jsou na webu jen jedny tabulky, tak bych styloval prostě #main table (#main je můj inner div pro hlavní obsah)
Pro obecně položky (cokoliv vypsané z databáze) používám .item, často přidávám zas další třídy typu bližší určení, název tabulky ze které vypisuji či např odd / even.
Navíc nově používám pár měsíců html5, takže můžu používat takové ty „article“ atd. a pojmenovávání se vyhnu úplně.
Obecně u tabulek (atd.), které vypisují nějaké funkce, považuji za dobrý zvyk dát jako jednu z tříd název oné funkce. Takže pak se jednoduše změní vzhled všeho, co vypisuje jedna funkce, mohu funkci změnit a s ní i upravit vzhled atd. Hlavní css vlastnosti pak nastavuji v té globální třídě pro funkci a pomocí specifické třídy tabulky pak už jen měním specifické rozdíly.
[6] Vašek Chromický | 10. 8. 2011 v 18.29
K Petrovu [#4] dopním, že mám v podstatě podobný styl, ale selektory jako „body.stories #content .col-left .list .item“ jsem opustil kvůli výkonnosti. Browser (který čte selektory zprava doleva) pak pro každý element na stránce s třídou „item“ nemusí projíždět DOM navrch až k tagu html, jestli některý z rodičů náhodou není třídy „list“.
Částečně to lze řešit použitím zobáčku „.list > .item“, ale to už raději vytvořím třídu „stories-list-item“ (za podpory LESSu), a browser nemá nad čím přemýšlet. Takový „.stories-list-item.selected“ je taky zcela v pořádku.
Naopak vůbec nejpikantnější je definovat třídy jako „.maloPouzivana span“ (za span lze dosadit i a/p/div a jiné hojně použivané elementy). Pak browser chodí až navrch pro každý druhý element na stránce.
[7] manakmichal | 23. 8. 2011 v 1.10
Já už do tříd zapracovávám téměř jen mikroformáty a vlastní odvozeniny. Pokud je potřeba, vytvářím globální jednoznačně definované třídy.
Obecně se snažím, kvůli správě souborů a rozšířitelnosti, s třídami šetřit, protože to jde i přes jedno id # a potomky. Kód je pak i čitelnější a menší.
Ale je to také projekt od projektu.
[8] Peter Kahoun | 25. 11. 2011 v 23.21
Jablka v podstatě nepoužívám, protože s takovými prvky se nesetkávám prakticky vůbec. Pokud kóduji svůj návrh, mám poměrně dobrou představu, jak moc je vzhled prvku vázán k obsahu a jak bych měl navrhnout obecnou třídu (zda vůbec). Pokud kóduji cizí návrh, který bude rozvíjen, volím pojmenování, které mají minimální nebo žádnou vazbu na vzhled. Nakonec je naivní předpokládat, že CSS kód může být navržen, rozvíjen pouhým přidáváním definic a přitom zůstat srozumitelný a efektivní — v žádném případě: buď je potřeba se smířit s redundancí, neefektivitou kódu, nesouladu pojmenování a funkce (ano, s takovým kódem se dá žít dlouho) anebo rafactorovat, což je pochopitelně proces nepříjemný.