Největší nedostatek CSS (kodéra)

Komentáře (14)

k formuláři

RSS kanál komentářů

1. • Komentář číslo: 1
   • nepřečtený*
   • Jméno: David Grudl
   • Odesláno:
     5.8. 2012 — 21:59

   Souhlas s každým slovem.
2. • Komentář číslo: 2
   • nepřečtený*
   • Jméno: Jakub Jarabica
   • Odesláno:
     5.8. 2012 — 22:09

   Súhlasím, imho veľa programátorov/kó­derov si neuvedomuje najmä to, že treba voliť správnu mieru abstrakcie vzhľadom na veľkost riešeného problému.
3. • Komentář číslo: 3
   • nepřečtený*
   • Jméno: paranoiq
   • Odesláno:
     5.8. 2012 — 22:11

   kodérský minimalismus je špatná cesta?
4. • Komentář číslo: 4
   • nepřečtený*
   • Jméno: Martin Michálek
   • Odesláno:
     5.8. 2012 — 23:00

   To, že chybí pravidla prošlá myšlenkovou revolucí není pravda. Je ale pravda, že to nejsou žádné výrazné „školy psaní CSS“, ale spíš kostičky puzzle, ze kterých si to kóder s enormním zájmem může poskládat sám.

   U mě ty kostičky tvoří pokusy/omyly z minulosti, podstatné myšlenky SMACSS, nějaký CSS preprocesor a víceméně vše z Idiomatic CSS. Doufám, že mi lenost dovolí o tom někdy napsat víc.

   Samozřejmě – důležitá je i otázka v jakých situacích spravovatelnost řešit. Neexistenci výrazných myšlenkových škol psaní CSS si částečně vysvětluji tím, že většina kóderů a projektů se bez hlubokého přemýšlení o spravovatelnosti CSS krásně obešla. To se myslím s CSS3 zlomí.
5. • Komentář číslo: 5
   • nepřečtený*
   • Jméno: Zdeněk Košťál
   • Odesláno:
     5.8. 2012 — 23:32

   Když jsem začal kódovat, tak jsem se s tím taky dost potýkal (hlavně na větších projektech), ale poslední dobou tu snahy o nějakou standardizaci jsou – mně konkrétně se líbí SMACSS. Jasně – nemusí to být dogma, ale pár chytrých myšlenek tam je… a návrhovým vzorem bych to klidně nazval :).

   Důležitou úlohu v tom ještě sehrají i CSS preprocessory – build systém je práce navíc a ne každý to dokáže, takže věci jako LESS/SASS/Stylus určitě přijdou vhod – člověk dokáže docela dobře separovat kód s minimem práce „navíc“.

   Ohledně pojmenování souhlas – to je subjektivní a dost neřešitelný problém, který za nás žádný vzor nevyřeší. To už jen záleží na tom, jaký cit a zkušenosti kodér má…

   Tyhle všechny snahy jsou sice fajn, ale člověk musí chtít – možná by někdo měl prošlápnout cestičku a napsat na toto téma i české články… konkrétně na Martinem zmíněné SMACSS / Idiomatic CSS jsem tuším nečetl žádný český článek.
6. • Komentář číslo: 6
   • nepřečtený*
   • Jméno: Jonáš K.
   • Odesláno:
     6.8. 2012 — 0:48

   Já bych s tvými myšlenkami asi spíše nesouhlasil ale delší rozepisování se mi teď nechce.
   Články jak psát „správné“ CSS jsem měl již několikrát v plánu ale čas mi to nedovoluje.

   Nicméně by mne zajímalo, kdo z vás má reálné zkušenosti s prací na velkém projektu v rámci týmu kodérů.
7. • Komentář číslo: 7
   • nepřečtený*
   • Jméno: Kahi
   • Odesláno:
     6.8. 2012 — 0:54

   [3] paranoiq: Minimalistický kód není připravený na změny.

   pokusy/omyly z minulosti, podstatné myšlenky SMACSS, nějaký CSS preprocesor a víceméně vše z Idiomatic CSS

   [4] Martin Michálek: něco podobného bych měl snad taky, ale stále mi to přijde jako příliš velký (volný) rámec. SMACSS se mi moc líbí, ale je to tak na půlcestě k mé představě.

   Na příčině bychom se shodli.

   [5] Zdeněk Košťál: mohl bys trochu rozvést téma přínosnosti preprocesorů? Klidně včetně příkladu. Díky.

   Ano, myslím že logiku pojmenovávání může řešit to, čemu říkám „návrhový vzor“.
8. • Komentář číslo: 8
   • nepřečtený*
   • Jméno: Kahi
   • Odesláno:
     6.8. 2012 — 0:56

   [6] Jonáš K.: Děkuji za nesmírně přínosný komentář.
9. • Komentář číslo: 9
   • nepřečtený*
   • Jméno: Kahi
   • Odesláno:
     6.8. 2012 — 1:09

   Tímto bych chtěl případné čtenáře ponouknout ke kladení otázek, zpochybňování názorů nebo popisování vlastních názorů či zkušeností.

   Např. téma co by návrhový vzor obsahovat (ne)měl je zajímavá otázka. Mně přijde, že třeba Idiomatic CSS href=„https:/­/github.com/ne­colas/idiomatic-css/“ rel=„nofollow“>https:­//github.com/ne­colas/idiomatic-css/ je z větší části soupis coding standards, které sice ke spravovatelnosti napomáhají, ale jeví se mi spíš jako estetické vylepšení. (Ve srovnání s otázkami typu „jak moc zanořované psát selektory, jestli tuto míru standardizovat, jestli je efektivnější takové pravidlo formulovat striktně nebo volněji“.)
10. • Komentář číslo: 10
    • nepřečtený*
    • Jméno: srigi
    • Odesláno:
      6.8. 2012 — 8:04

    Koderinou sa zaoberam uz velmi dlho a narozdiel od vacsiny PHPckarov ma CSSko velmi bavi. Celu oblast preto podrobne sledujem. A musim suhlasit, ze tu chyba nejaky uceleny subor best-practises v dostupnej forme.

    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.
11. • Komentář číslo: 11
    • nepřečtený*
    • Jméno: Patrik Illy
    • Odesláno:
      6.8. 2012 — 8:12

    SMACSS se mi líbí a naznačuje, podle mě, správný myšlenkový směr. Zajimalo by mě, jak moc máte (komentátoři) nastudované BEM a OOCSS a jak moc se tyto přístupy lisí filozofii?
12. • Komentář číslo: 12
    • nepřečtený*
    • Jméno: Martin Michálek
    • Odesláno:
      6.8. 2012 — 9:07

    [7] Kahi:
    K Idiomatic – ono je to dost čerstvé na zásadnější soudy, ale z jedné části se překrývá s mým pokus/omyl knowhow a z části doplňuje díru, která vznikne tím, že začneš používat SMACSS a… prostě ti ještě něco chybí. Mrkni třeba na sekci Preprocessors, tam má odpovědi i na to co píšeš: https://github­.com/necolas/i­diomatic-css/#preprocessors-additional-format-considerations

    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.
13. • Komentář číslo: 13
    • nepřečtený*
    • Jméno: Jonáš K.
    • Odesláno:
      6.8. 2012 — 10:22

    Petere, ruku na srdce, tvuj clanek je na tom obdobne.
    Zminujes veci, ktere jsou v zahranici omylane porad dokola. Tve myslenky mi prijdou zajimave, snazis se neco naklepnout ale nevysvetlis to do konce, neuvedes priklad.
    Nicmene clanek splni svuj ucel v ramci komentaru, kde se neco zajimaveho objevi.

    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.
14. • Komentář číslo: 14
    • nepřečtený*
    • Jméno: Kahi
    • Odesláno:
      8.8. 2012 — 23:31

    [11] Patrik Illy: BEM nemám nastudovaný vůbec. Z toho co jsem četl nebo viděl jsem ani nepochopil, co za problémy běžného kodéra to (jak) řeší.

    [12] Martin Michálek: 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] Jonáš K.: 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ář.

Přidat komentář