Několik dobrých návyků na úvod

Jedině s preprocesorem

Používání Bootstrapu bez preprocesoru nelze nazvat jinak než slepou uličkou. Používat zbytečně celý vygenerovaný Bootstrap, když z něj využijeme jen několik málo procent, je špatný nápad. Tím spíše dnes, kdy se díky (nikoli kvůli) mobilnímu internetu musí znovu hledět na výslednou velikost stránek. Naklikat si potřebné komponenty a vygenerovat si CSS přímo ze stránek Bootstrapu je už lepší řešení, ale stále dost nešikovné. Nainstalovat si vše potřebné, co k používání preprocesoru potřebujeme, je otázka několika minut a benefity, které používáním preprocesoru získáme, jsou velké. A i když existují porty Bootstrapu do SASSu i Stylusu, je zdaleka nejlepší a určitě nejjednodušší používat nativní LESS.

Nešťourat se v Bootstrapu

Nedělat v LESS modulech Bootstrapu žádné změny je jednoznačně dobrý nápad, který oceníte při aktualizaci na novější verzi frameworku. Čestnou výjimku tvoří soubory bootstrap.less, kde se importují potřebné moduly, lépe řečeno zakomentují ty nepotřebné, a variables.less, ve kterém si můžeme Bootstrap „obléct“ do svých barev a fontů, nastavit paddingy a mnoho dalšího.

Zvažte, kdy je vhodné Bootstrap použít

I když v poslední době používám Bootstrap téměř na vše, jednu čestnou výjimku jsem za poslední rok měl. Byl to atypický web, kde by bylo použití Bootstrapu spíše kontraproduktivní, proto jsem z něj použil pouze mixiny. Určitě je tedy dobré předem myslet také na to, zda je opravdu potřeba Bootstrap použít.

Když už ho použijete, využijte ho

Na naprostou většinu prvků, které „vypadnou“ od grafika, můžete použít nějakou Bootstrap komponentu. A to platí i v případě, že grafik s použitím Bootstrapu předem nepočítal. Když už Bootstrap používáme, je z mnoha důvodů (budoucí úpravy, práce více lidí v týmu…) dobré maximálně využít jeho komponenty. Takže předtím, než začnete psát vlastní HTML, je dobré zamyslet se, zda je to opravdu potřeba.

Neškrábat se pravou rukou za levým uchem

Někdy je ale vlastní HTML nejlepší řešení. Je v grafickém návrhu prvek, u kterého váháte, jakou Bootstrap komponentu pro něj použít? Možná bude nejlepší nepoužít žádnou a napsat si HTML i CSS kompletně sám. Čím déle Bootstrap používám, tím více se snažím využívat maximálně využívat jeho komponenty, ale vlastní HTML je někdy to nejjednodušší a nejlepší řešení.

Jak Bootstrap používáme u nás

Prohlédněte si část našeho interního frameworku, ve kterém vyvíjím nové šablony.

1) Ve složce /bootstrap jsou všechny LESS moduly Bootstrapu. A jak jsem psal výše, v této složce se vůbec nešťourám (zde dokonce bez výjimky).
2) Ve složce /modules mám připravené vlastní LESS moduly – jsou tam ty „základní“, které používám na každém projektu. Projekt od projektu se pak rozhoduji, zda se pro přehlednost vyplatí přidat nějaké další.
3) Poslání souboru ie8.less je myslím jasné už z jeho názvu a netřeba vysvětlovat. Jsem rád, že tento soubor zůstává poslední dobou téměř nebo úplně prázdný :-)
4) Soubor main.less si zaslouží vlastní nadpis.

main.less

V tomto souboru se importují jednotlivé moduly, kompiluje se z něj také výsledné CSS. Nejdříve se naimportují potřebné Bootstrap moduly. Jak si můžete všimnout, „v základu“ mám pouze ty nezbytné (scaffolding, grid…) a ty „nezbytné“ (forms, buttons), zbytek je zakomentovaný. Následně importuji svoje moduly, na závěr pak ty responzivní. Responzivní moduly jsou pojmenované tak, jak má své responzivní třídy/proměnné pojmenované Bootstrap, tedy se suffixem xs, sm, md a lg.

Popis jednotlivých souborů

• variables.less – toto je soubor, který v podstatě vždy upravuji jako první. Přepisuji zde hodnoty výchozích Bootstrap proměnných a také deklaruji vlastní proměnné.
• bootstrap.less – soubor s mírně matoucím názvem. Zde přepisuji CSS pro jednotlivé Bootstrap komponenty. Pokud je CSS u některé komponenty hodně rozsáhlé, pro přehlednost pro ni vytvořím samostatný modul.
• common.less – zde píšu všechno ostatní CSS. A stejně jako u předchozího bodu, pokud se to v zájmu přehlednosti vyplatí, vytvořím pro některé prvky vlastní modul. Běžně to bývá pro hlavičku, patičku, menu, boxy atd.
• responzivní moduly si zaslouží podrobnější představení.

Mobile first

„První pravidlo Media queries je to, že žádná media queries nejsou,“ jak pravil Honza Sládek. A já si poslední dobou vzal jeho slova k srdci. Proto nejprve píšu CSS pro všechny prohlížeče/rozlišení a teprve nakonec přidávám styly pro různá rozlišení, počínaje sm, přes md až po lg. Začnu u sm rozlišení a postupně „přidávám“ až k desktopu. Soubor responsive-xs je naopak pro nejmenší displeje – s mobile first přístupem bývá tento soubor často prázdný, ale občas je potřeba něco definovat jen pro malé displeje. Tolik krátká, leč velmi důležitá odbočka od Bootstrapu.

Závěrem

Tolik tedy o mém pohledu na Bootstrap a na práci s ním. Budu se těšit na vaše komentáře, ve kterých se můžete také podělit o své zkušenosti a workflow, které s Bootstrapem používáte.

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!