Zásady psaní respektujícího CSS

Vzhůru dolů 05.08.2018 02:02 Zásady psaní respektujícího CSSNaposledy upraveno: – Autor: Martin Michálek Pište kód jednotně a hlavně tak, aby se dobře četl jiným nebo třeba vám samotným za rok. Počítejte s tím, že lidé umí CSS. Nic nad tím není jisté. Pište proto CSS kód a moc si jej neupravujte. Respektujte vlastnosti lidí i CSS. Tyhle zásady psaní vycházejí z OOCSS, BEM a dalších přístupů a nástrojů. Předpoklady Design vašeho projektu je vymyšlený komponentově a systematicky, ideálně podle principů atomického designu. Výjimky jsou možné, ale nesmí být moc časté. Píšete čisté nebo preprocesorové CSS, nikoliv CSS v JS. Styly nezapisujete výlučně pomocí užitkových tříd. Doporučené nástroje Píšeme čisté CSS nebo pomocí preprocesorů. Doporučuji dnes převládající Sass v konvenční SCSS syntaxi. Kód zpracovává postprocesor a sestavovací nástroje . Díky tomu můžeme automaticky dělat různé hacky v kódu, které není pěkné dávat do čteného kódu – například minifikaci nebo přidávání prefixů. Při kompilaci nastavujeme Source Maps, abychom v prohlížeči viděli napojení na zdrojové soubory. Pro sjednocení nastavení editorů používáme EditorConfig. Prettier nám automaticky opravuje formátování v kódu ještě před nahráním změn do repozitáře. Pro kontrolu psaní používáme Stylelint, nejlépe v mé výchozí konfiguraci.
 1) Obecná pravidla 1.1) CSS píšeme s respektem k vlastnostem jazyka Bereme ohled na kaskádu, hlavně specifičnost a pořadí selektorů, a také na globální povahu jazyka. // Cilem je, aby vsechny nadpisy mely velikost 1.25rem // a varianta pouzivana v .box pak velikost 1.5rem. // Spatne: // Nedrzime specificitu nizko a nemame spravne // poradi, proto nas zachrani jen !important .heading--large .box h2 // Dobre: .heading .heading--large 1.2) Nevytváříme zbytečně konstrukce neobsažené v CSS Pokud to není nezbytně nutné nebo to výrazně nepomáhá čitelnosti kódu, netvoříme proprietární funkce v preprocesorech. CSS umí číst všichni, na rozdíl od specifických konstrukcí. V deklarativní části píšeme jednoduchý kód co nejvíce podobný běžnému CSS. // Dobre: .box // Spatne: .box Jsou ale samozřejmě opodstatněná použití mixinů – v programátorské části kódu. Například při generování mřížky layoutu, animací a dalších extrémně se opakujících částí stylů. 2) Soubory a struktura 2.1) Kód rozdělujeme do malých souborů Jeden problém řeší jeden soubor. Vyhýbáme se souborům míchajícím více komponent, funkcí nebo o délce výrazně přesahující 200 řádků kódu. 2.2) Soubory umísťujeme do adresářů podle kategorií, v nichž specificita roste a počet dotčených HTML elementů se snižuje Tipy pro metody organizace: jednoduché projekty. Složitější podle ITCSS. // Dobre: @import "base/blanka.scss"; @import "base/typography.scss"; @import "components/box-variables.scss"; @import "components/box.scss"; @import "components/heading.scss"; @import "utilities/margins-paddings.scss"; Další doporučení: V adresáři se zdrojovým CSS máme jeden hlavní soubor. Všechny ostatní jsou v adresářích. Víme tak, který otevřít jako první. Doporučuji jej pojmenovat index.scss. Atomické soubory sestavovacím nástrojem skládáme do větších kvůli efektivitě při rychlosti načítání. 3) Psaní komponent 3.1) OOCSS: používáme objektový zápis Držíme se hlavních pravidel: CSS není závislé na struktuře HTML. Specifičnost selektrů držíme co nejníže. Komponenta nesmí být závislá na rodiči. Všechny prvky komponenty prefixujeme jejím názvem. Vyhneme se tak možným problémům s kolizí komponent nebo jejich částí. Více je v textu o OOCSS. // Spatne: .page-cart .box ul > li // Dobre: .box-item-small 3.2) BEM: pojmenováním odlišujeme bloky, elementy a modifikátory Pomůže nám to jednoznačně určit typ třídy už z HTML nebo dokumentace. Více je v textu o BEM. // Spatne: // Dobre: Další doporučení: Nepojmenováváme komponenty nebo funkce zkratkami. My si je možná zapamatujeme, ale porozumění ztížíme ostatním. Kód složitějších komponent dělíme na deklarativní a programátorský . Máme tak např. box.scss a vedle něj box-mixins.scss nebo také box-variables.scss. Samozřejmě jen v případě, kdy si to množství kódu dotčených částí žádá. Vycházíme ze vzorové šablony SCSS souboru. Strukturu souboru činíme zjevnější pomocí Markdown nadpisů. Do hlavičky přidáváme odkaz na dokumentaci. Pod hlavičkou struktura komponenty pro snadnější vstřebání složitějších celků. Části komponent drží pořadí podle metodiky BEM. BEM komponenty lintujeme pomocí selector-bem-pattern, pluginu do Stylelintu. 4) Psaní kódu v deklaracích 4.1) Základní formát psaní podle Prettier Základní formát psaní přebíráme od Prettier. Například: Odsazujeme dvěmi mezerami. Takové odsazení se totiž vykresluje stejně ve všech editorech. Každý selektor v deklaraci patří na vlastní řádku. Mezi deklaracemi je vždy jeden volný řádek. Za čárkami v hodnotách bude vždy mezera. Desetinné hodnoty mají na začátku vždy nulu. Tento i jiné principy přebíráme z nevývojářského prostředí. Vyhýbáme tak mimojiné silně nepřirozeným konstrukcím jakko -.25rem. Prettier máme nainstalovaný tak, aby nám všechny prohřešky rovnou sám opravoval ještě před odesláním do repozitáře. 4.2) Pokročilejší formát kódu hlídá Stylelint Stylelint používáme v této konfiguraci. Příklady nastavení: Nejvyšší úroveň zanoření deklarace je 1. Všechny barvy v hexa tvaru musejí být uvedené malými písmeny. Opět to přebíráme z pravidel klasické typografie. Lidem se malá písmena lépe čtou. Nejsou povoleny vendor prefixy. Od toho máme postprocesory, že ano? Nejvyšší povolená specificita je 0,3,0 – tři třídy. Pokud chcete být přísní, dejte 0,2,0. V kódu psaném metodikou BEM by se teoreticky vyšší specificita vyskytovat neměla. Nejsou povoleny id selektory . V hodnotách funkcí, deklarací písem, vlastnosti content nebo selektorech se vždy používají dvojité uvozovky. V principu je sice možné na většině míst uvozovky nepoužívat, jenže ve výjimečných situacích jsou vyžadovány: například u selektorů podle atributu nebo definici formátu písma také nefunguje). 4.3) Vlastní hodnoty zobecňujeme co nejvíce, pravidla nebo selektory co nejméně Zobecňování do lokálních a globálních proměnných je správné: // Spatne: .box // Proc zrovna tento breakpoint? } // Dobre: .box } Další doporučení: Pokročilé vlastnosti preprocesorů jako @extend nebo placeholdery pokud možno vůbec nepoužíváme. Obvykle dělají více škody než užitku. Mění například pořadí v kódu a podobně jako mixiny vytvářejí abstrakci v kódu specifickou pro náš projekt. Mixiny používáme jen pokud jsou nezbytně nutné pro pochopení kódu nebo odstranění extrémního opakování deklarací. Třeba pro generování mřížky layoutu nebo u složitějších animací. Direktivy @include dáváme na začátek deklarací, jsou důležité. 4.3) Šetříme se zanořováním Nezanořujeme do vyšší než první úrovně. Povoleno je jen zanoření pro pseudotřídy nebo Media Queries. Ampersandové zanoření v selektorech nepoužíváme. Komplikuje nalezení správného selektoru a kodér ztrácí přehled nad selektorem, který vytváří. Vyhýbáme se dlouhým zanořeným deklaracím – monolitům.
 // Spatne: .box } } } // Dobre: .box .box__heading .box__heading--large } 4.4) Kód píšeme podle specifikace, hacky automatizujeme Kód píšeme vždy podle specifikací W3.org. Části, které potřebujeme pro ošetření specifických prohlížečů, automatizujeme. Například vendor prefixy přidáváme Autoprefixerem. Další doporučení: Pořadí pravidel: U složitějších deklarací dáváme důležité vlastnosti na první místo: pozicování, box model a pak teprve ostatní pravidla. Matematické výrazy zapisujeme vždy v závorkách a s mezerami uvnitř Např. margin-top: ;
 5) Komentáře 5.1) Pokud je to potřeba k pochopení důvodu a kontextu, vždy ke kódu píšeme komentář V jiných jazycích je potřeba okomentovat důvod, v CSS ještě kontext. Někdy má na prohlíženou část vliv předcházející kód. Jindy prohlížená část ovlivňuje následující. Více je v praktické ukázce v článku. // Dobre: .box Další doporučení: Ponecháváme šířku řádky pro komentáře na maximu 80 znacích, aby se to dobře četlo. Komentáře v kódu píšeme anglicky. Nikdy totiž nevíme, kdo do projektu nastoupí po nás. Pokud vybereme češtinu, píšeme bez diakritiky. Velká část česko-slovenských vývojářů používá anglickou klávesnici. Standardně používáme tiché, preprocesorové komentáře . CSS komentáře jen v hlavičkách souborů kvůli snadnějšímu dohledání v neminifikovaných souborech. Pro výraznější oddělení částí souborů používáme strukturální komentáře vycházející z Markdown nadpisů. Vzor. Nepoužíváme // TODO komentáře. V kódu jsou obvykle k ničemu. Zakládáme úkol do systému úkolů. U složitějších komentáře používáme referenci na ovlivněný kód. Ukázka. To je vše, děkuji za pozornost a respektujte prosím povahu CSS. Verze: 1.5 Zdrojový soubor: rcss-zasady.md Náměty na doplnění, diskuze a pull requesty jsou vítány Stejně jako další obsah ze Vzhůru dolů jej můžete upravit a využít pro vlastní účely s podmínkou dodržení licence Autor nabízí konzultace a školí psaní organizaci CSS kódu Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .

Čítať celý článok >>