[12] Díky. Pro ostatní čtenáře vytahuji z Idiomaticu, co mi přišlo k tématu:

• Avoid systematic use of abbreviated class names. […]
• Pick an understandable and consistent naming pattern that makes sense both within HTML files and CSS files.
• Selectors for components should uses class names; avoid the use of generic tags and unique ids.

• [Preprocessors] Limit nesting to 1 level deep. Reassess any nesting more than 2 levels deep. This prevents overly specific CSS selectors.
• Avoid large numbers of nested rules. Break them up when readability starts to be affected. Preference to avoid nesting that spreads over more than 20 lines. [Tomu ale asi nerozumím.]
• Always place @extend statements on the first lines of a declaration block.
• Where possible, group @include statements at the top of a declaration block, after any @extend statements.

[13] Příteli, jestli něčemu nerozumíš, rád vysvětlím, uvedu příklad, stačí říct.

Spravovatelnosti je dosaženo … správnou tvorbou selektorů a pojmenováváním tříd … snažím se uniknout sémantice pojmenovávání prvků

Zajimalo by mne kde presne vidis chybu a jak ji resit.
Myslim, ze semanticke pojmenovavani prvku je vzdy na miste a prinasi prehlednost nejen do CSS ale i do JS.

Řekněme, že je několik způsobů, jak prvky pojmenovávat (nebo nepojmenovávat) a taky jak tvořit selektory. Například je asi jasné, že hloubka selektoru by měla být minimální, protože hluboká závislost na předcích je opakem komponentového přístupu, který se zdá být nevyhnutelným :-).

Sémantické pojmenovávání prvků není na místě, protože vzhled a sémantika nemusí jít ruku v ruce. Ale i sémantika se dá pojímat konkrétněji a abstraktněji a asi bude pro orientaci v kódu lepší pojmenovat prvek .article-list, ačkoli to nemusí platit na věky, než .list-type-4 a kochat se neprůstřelností.

Myslel jsem to možná spíš tak, že zabývání se obsahem (z hlediska kodéra) je docela vyhozený čas, byť může jít o zajímavou meditaci – snažit se pojmenovat blok plný dummy textů.

Znamena to, ze pises obecneji nebo naopak?

Nevím, jak to myslíš. Píši myslím dost v duchu SMACSS/Bootstrap.

Obcas totiz neni jina cesta a zanorit musime hloubeji.

Občas není jiná cesta, ale ve všech ostatních případech může standardizace fungovat. Nejde třeba jen o hloubku zanoření, ale co takhle důsledně používat selektory přímého potomka a selektor nepřímého brát jako výjimku, která musí projít zvážením? Anebo by to způsobilo spíš potíže? (Nevím.)

Díky za komentář.

Pises „správnou tvorbou selektorů a pojmenováváním tříd“
a „snažím se uniknout sémantice pojmenovávání prvků“

Zajimalo by mne kde presne vidis chybu a jak ji resit.
Myslim, ze semanticke pojmenovavani prvku je vzdy na miste a prinasi prehlednost nejen do CSS ale i do JS.

K prehlednosti a konzistenci dopomohou, alespon castecne, jiz zminovane SMACSS/Idiomatic.

Od okamžiku, kdy jsem si osvojil schopnost napsat kód tak
čistě a úsporně, jak to jen jde, se z této idee snažím vymanit
a projekt od projektu je můj kód robustnější.

Znamena to, ze pises obecneji nebo naopak?
Osobne mi prijde obecnejsi kod lepsi. Rad si poslechnu v cem je pripadne nevyhoda.

Co se tyce zanorovani, tak urcite cim mene, tim lepe. Standardne se vlezeme do 2–3 ale o standardizaci nemuze byt imho rec. Obcas totiz neni jina cesta a zanorit musime hloubeji.

mohl bys trochu rozvést téma přínosnosti preprocesorů?

Za mne,

• moznost rozdelit jedno CSS na nekolik mensich logickych celku
• rychlejsi psani kodu (odpadaji prefixy apd.)
• prehlednejsi CSS a dedicnost

Nicmene zatim chybi nastroje, ktere by v ramci teamu fungovali 100%. Delali jsme na velkem projektu pro ING, projekt zastitovali lide z google a obcas nam kazdemu kompilator delal psi kusy. Taky prace win vs mac je obcas ubijejici.

Ta kombinace SMACC/Idiomatic/LESS mi připadá hrozně elegantní. Pro názornost jsem vyhrabal jeden menší modul z chystaného nového webu kina Světozor kde to víceméně (zatím kromě stylu komentářů) držíme —

// --- Modul seznam dlazdic ---
// (blok se seznamem v zalozkach na uvodni strance, v seznamu cyklu nebo fotogalerii)

.tiles {
        position: relative;
        background: @tilesBgColorFallback;
        background: @tilesBgColor;
        padding: 26px 0 22px 24px;

        // Varianta: Na uvodni zalozce posunujeme nize kvuli navigaci pro novinky a udalosti
        &.tiles_splash {
                padding-top: 60px;
        }

        > h2 {
                font-size: 33px;
                line-height: 2*@baseLineHeight;
        }
}

LESS v tomhle případě kromě úspornosti podporuje i čitelnost.

Su tu sice SMACSS alebo OOPCSS, mne ale pripadaju ako nejaka referencna prirucka. Nasadenie do realneho velkeho projektu, spolupraca timu, moc pokryta nie je.

Velkou zmenou bol prichod Twitter Bootstrap. Mne to dost otvorilo oci, ako pomocou semantiky na strane HTML definovat vzhlad. Stale vsak nie je pokryta modularnost (widgety, komponenty). A prave tu sa nedavno objavil perfektny blogpost od Yandexu, ktory predstavil techniku BEM (nekce sa mi to hladat, pisem v MHD, pogooglujte).

BEM odporucam nastudovat kazdemu, kto pouziva znovupouzitelne widgety. Treba si z toho zobrat zaklad (konvencie na pomenovanie) a pomaly a dokladne to implementovat.

Ja som prave dokoncil vacsi projekt s pouzitim BEM konvencii a musim si to pochvalit. Bohuzial to nebol projekt „from scratch“, inak by som si presadil aj pouzitie TW Bootstrap. Ale uz sa neviem dockat projektu, kde vyuzijem vsetko co je teraz dostupne: bootstrap, Sass a BEM.