29 komentářů k článku Proč jsme zvolili atomické CSS:

    1. Martin Hassman

      Re: Nenávidím overclassing a atomické CSS

      Je možném rozepsat proč? Je totiž strašně hloupé psát komentáře jen o svých pocitech, ze kterých si ostatní nic moc nevezmou. Jaké jsou hlavní důvody toho, proč považujete tento způsob za hloupý?

      1. Mlocik97

        Re: Nenávidím overclassing a atomické CSS
        5 dôvodov:
        – jde proti tomu na čo bol CSS určený a jak mal byť používaný…
        – neprehladný, zaplevelený, nechutný HTML kód.
        – ťažké úpravy (trebárs CSS Grid Areas v HTML classoch? asi ne no…)
        – opakovanie
        – omedzujúca funkcionalita… stejne CSS budete musieť otvárať, kedže už vidím jak by ste 255^3 farieb nacpali do classov a cez 20 tisíc^2 rozmerov veľkostí v rôznych jednotkách.

        1. Vít Heřman

          Re: Nenávidím overclassing a atomické CSS

          • CSS byl určen pro separaci stylů od HTML. Pro webové aplikace často irelevantní důvod. Přineslo by to tedy něco, co nepotřebuji v neprospěch toho, co potřebuji.
          • opticky ano, ale praktický přínos je jasný. Na jednom místě je to, co spolu souvisí „neoddělitelně“
          • ???
          • prašť jako uhoď. Buď se opakují třídy v HTML nebo pravidla v CSS. Nebo se nějaká opakování zapouzdří do abstrakcí, jejichž množství ale také k přehlednosti a udržovatelnosti nepřispějí
          • správně omezená funkcionalita je benefit, který vede k přehlednosti a udržovatelnosti. takže v daném kontextu je to spíš dobrá volba

          Vaše argumenty nijak nereflektují kontext a potřeby, které autor řešil, ač je v článku popsal. Moudrost od hlouposti lze rozeznat spíše hodnocením souladu volby s vytknutými cíli a potřebami. Nikoli podle volby samotné

        2. Martin Hassman

          Re: Nenávidím overclassing a atomické CSS

          👍👍 Děkuji za rozepsání! (Poděkování neznamená souhlas.)

        3. Martin DržkaAutor příspěvku

          Re: Nenávidím overclassing a atomické CSS
          Vít Heřman to sepsal lépe než já, takže jen doplním…

          1) Atomické CSS třídy nejsou inline styly, nedefinují atributy na HTML. CSS vlastnosti jsou stále definované v separátním souboru. Jen lze třídy častěji znovu použít. Furt je tam ale zmiňovaná separace obsahu od vzhledu.

          2) Tady souhlas, nicméně dá se na to zvyknout a v článku je to zmíněno. Furt si stojím za tím, že výhody v našem případě převládají. Mimochodem „zaplevelené“ CSS Vám nevadí?

          3) Ano, CSS Grid (narozdíl od Flexboxu) si zatím nedokážu představit abstrahovat do single-purpose tříd. CSS Fakturoidu ale nejsou striktně atomická, můžeme je psát komponentově (nebo chcete-li sémanticky). CSS Grid jsme zatím nepotřebovali a v době vzniku nebyl ani zásadně podporován. Časem uvidíme, zda bude potřeba a jak s tím naložíme.

          Možná by stálo za to prozradit, na jakém typu projektů pracujete (prezentační weby / aplikace). Jakou CSS metodologii (nebo architekturu) upřednostňujete. Nebo jaký CSS framework používáte. Našel bych mnoho příkladů, kde (zvlášť striktně) atomické styly nedávají smysl. Třeba jsou vaše projekty právě tohoto typu.

          1. Martin Hassman

            Re: Nenávidím overclassing a atomické CSS

            Já si zatím pro sebe brainstormuji tyhle tři zápisy:

            <p><font color="red">Text</font></p>
            <p style="color:red">Text</p>
            <p class=".color-red">Text</p>
            

            Známe dobře z historie, že ano?

            Všechny tři mají stejnou linku, která jasně odrazuje. Těžko si můžeme pomoct, abychom i v tom posledním neviděli ten první, středověký. Na druhou stranu je v každém kroku pokrok. Každý z těch kroků = nová generace. S lepšími možnostmi. Hledám pro sebe, jak moc mám ještě nenávidět ten poslední zápis. A hlavně kdy ano a kdy ne.

            Většiny výtek, které napsal Mlocik, jsem si byl už vědom. Nezaskočily by mě, snad jim předejdu. Takže pro mě nemají smysl. Myslím, že nikdo snad nebude vytvářet třídy pro všechny barvy, ale bude mít předem danou paletu barev – třeba v designovém manuálu/styleguide, který si tým sepíše – pro tu třídy vytvoří a pak už je sází atd., že jo? Podobně další výtky.

            Tady by asi pro příští text o atomickém CSS chtělo víc zdůraznit nějaká pravidla, která pomůžou se těm slepým uličkám vyvarovat, a která každý zřejmě nevidí. Možná něco, co ty Martine a další děláte podvědomě, ale do těch atomických návodů se to nedostane.

            1. Vít Heřman

              Re: Nenávidím overclassing a atomické CSS
              Myslím si, že hlavní přínos atomických CSS na Fakturoidu není ani tak o zápisu, ale o tom, že byl v podstatě na míru napsán takový malý a asi nepříliš obsáhlý DSL nad CSS, který narozdíl od sémantického přístupu nebude po stabilizaci vyžadovat téměř žádnou údržbu. Krom toho pokrývá jasně a přesně specifika projektu, reálně zjednodušuje stylování přesně takovým způsobem, který autor potřebuje. Toto nedokáže zajistit ani univerzální CSS framework. Třeba Bootstrap je vynikající a poměrně obstojně konfigurovatelný, ale vždy s vědomím, že bude lepší své potřeby přizpůsobovat Bootstrapu, než-li obráceně (chci-li ho opravdu využít).

              Jednoduše byla použitá správná věc pro daný úkol. Obhajoba obstála :-)

              1. Martin Hassman

                Re: Nenávidím overclassing a atomické CSS

                Zda obhajoba obstojí, to ukáže čas. Ale já nesoudím Fakturoid, zamýšlím se čistě obecně nad správným použitím technologií.

                Tahle formulace se mi líbí:

                na míru napsán takový malý a asi nepříliš obsáhlý DSL nad CSS
                

                O to bych se při úvahách o atomickém CSS opíral.

                1. Martin DržkaAutor příspěvku

                  Re: Nenávidím overclassing a atomické CSS
                  Základ knihovny vykrystalizoval někdy před rokem a půl. Od té doby se rozrůstá opravdu minimálně a vznikly desítky nových obrazovek aplikace. Nevím jak se povedla obhajoba, ale zatím se nám s mixem atomických tříd a komponent pracuje skvěle :)

                  Jen s tím DSL to IMHO není úplně pravda… Osobně jsem si na stejném stacku/architektuře (ano v mírně očesané podobě) vyzkoušel i několik soukromých projektů, menších/středních prezentační webů, a taktéž bez problémů. Jen jsem si jinak nakonfiguroval barevnosti, spacing škálu, typografii, apod. Výhodu atomických knihoven vidím mimo jiné v přenositelnosti na jiný projekt (ne každý). Píšu stejné názvy tříd, které znám téměř nazpaměť. Třída .d-b, bez ohledu na projekt, vždy nastaví display: block; a zároveň jsem si jistý, že nic nerozbije.

                  Nepochybuji, že stejný stack (s jinou konfigurací a opět trochu očesaný) použijeme i pro nový robotí web.

                  1. Vít Heřman

                    Re: Nenávidím overclassing a atomické CSS
                    To ale přesně vyhovuje definici DSL. Ono to omezení neznamená nutně na jeden projekt. Doménou může být klidně více (nejen!) vašich projektů. Důležité je, že to má limitovat přímé využití CSS. Koukal jsem na Fakturoid a je pravda, že .d-b jen mapuje na stejný výraz CSS. Ale celkově to nic nemění na tom, že jste si vytvořili vlastní výrazový aparát (jazyk) jako výrazně redukovanou podmnožinu CSS.

                    Koneckonců Bootstrap je také kombinace DSL a komponent. Jeho utility třídy nejsou ničím jiným, než DSL.

                    Neberte to ale dogmaticky. Spíš jsem toto označení použil proto, abych vynesl strukturální aspekt tohoto řešení a trochu potlačil povrchnější úvahy nad hezkostí/ošklivostí zápisu.

          2. Mlocik97

            Re: Nenávidím overclassing a atomické CSS
            Ja sa designu (teda ani CSS) moc nevenujem, pracujem najmä na web aplikáciách zväčša v Angulari, jinak Electron/Cordova aplikace, jinak jazyky JS (i node.js), Scala a Go. Zatial když som ptreboval psát CSS mi stačil objektový prístup s pravidlo „#kde .jak“ a zatím jak CSS znám (možno až tak moc jak Vy asi ne), tak mi to prijde ako celkom v pohode.

            1. Vít Heřman

              Re: Nenávidím overclassing a atomické CSS
              Ono to celkem v pohodě může být. Jde ale o další požadavky jako když třeba chcete maximalizovat re-using CSS tříd, potřebujete se v týmu orientovat v CSS třídách a CSS stylech, zabránit mrtvému CSS zejména na sdílených projektech, atd. Ad-hoc řešení, které dělal kolega pak je často peklo největší. Taky jsem hlavně programátor, byť s přesahem do kódování designu, ale důsledné OOCSS (a příbuzné metodiky) je zatím nejlepším vynálezem jak CSS dostat pod kontrolu. A ty atomické CSS ještě trochu posouvají hranice jinam a minimálně má smysl to prověřit.

            2. Martin DržkaAutor příspěvku

              Re: Nenávidím overclassing a atomické CSS
              Z vlastní (cca 15leté) zkušenosti s CSS vím, že přístup #kde .jak u projektu, který žije a permanentně se delší dobu rozvíjí, je opravdu cesta špatným směrem. Ostatně CSS původní robotí verze byly jasným důkazem.

  1. Tomáš Votruba

    Boží!
    Tenhle přístup se mi strašně líbí. Nemusím nic psát do css a přitom se mi web rodí pod rukama.
    Jedu amatérsky Bootstrap už několik let a jsem rád, že se ty utils classy stávají populárnější.

    Díky za shrnutí a vysvětlení proč a výhod a nevýhod!

  2. lenoch

    Nevím… mě to připadá jako by někdo začal propagovat spagetti kód a globální proměnné. Resp. nepochopil jsem důvody, proč to dělat. Jasně, pokud mám na všechno „sémantické“ šablony, např. alert_success, alert_danger, tak to může fungovat, ale jinak jsou jasné nevýhody: nekonzistence (každý to dělá jinak), nízká míra deskriptivnosti, obtížná změna designu, refaktoring musí změnit veškeré html, není schopné se přizpůsobit zobrazení v odlišných prostředích…

  3. Jan

    Tvrdit, že 3kB není mnoho v době omezených mobilních dat je nesmysl. Je to jen hra se statistikou, čtenář se podívá a řekne si, no opravdu 3kB nejsou takový rozdíl. Řekněme si kolikrát si můžeme takovou stránku bez „cache“ stáhnout při limitu 1GB (nezáleží na tom jaký je, vždy se to jen vynásobí nějakou pěknou konstantou). 1GB / 17kB ~ 60000 (bude to něco málo pod nebo přes, záleží zda počítáme GiB nebo GB). Pro tu menší verzi je to 1GB / 13kB ~ 80000 (viz nahoře). No a nyní si spočítejme o kolik takových stránek si můžu za měsíc prohlédnout více? No je to 17/13 ~ 1,308, což znamená, něco okolo 30% více stránek s menší verzí. Pro uživatele, který si ve 3. týdnu vyčerpal data to znamená, že by mu při nižší variantě mohli vydržet skoro celý další týden. A to už není zas tak zanedbatelné.

    1. Vít Heřman

      Re:
      To je teoretická úvaha, avšak zcela nevhodně aplikovaná. Předpokládáte, že uživatel využije celou svou mobilní kapacitu pro Fakturoid. Pro realistickou představu byste měl ale uvažovat realistický vzorek, třeba průměrný počet zobrazených stránek za měsíc nebo počítat s nějakým rozumným rozložením. Pak dojdete ke zcela opačnému závěru o té zanedbatelnosti :-)

    2. Dor

      Re:
      Autor udělal tu chybu, že napsal „rozdíl = 3 kB“. Kdyby napsal „rozdíl = 2%“, tak by neinspiroval k zavádějícím počtům se spoustou neověřených předpokladů. Mám spoustu výhrad k a tomickým css, ale velikost to opravdu není.

      BTW 60000 za měsíc? Tedy 2000 denně? To imho není úplně běžný use-case. Zato to 1 GB vcelku ano.

  4. jirkakosek

    V CSS chybí jedna úroveň abstrakce
    Tak samozřejmě je takový způsob zápisu CSS v podstatě prasárna, která jde proti duchu CSS. Podobně to má ale třeba i onen zmiňovaný Bootstrap, a bohužel to dnes nejde dělat o moc lépe. Co v CSS chybí, je možnost říci, že nějaká třída má zdědit vlastnosti z několika dalších tříd najednou. Tj. aby bylo možné v HTML zapsat něco ve stylu:

    <table class="tabulka-vypis">
    

    A v CSS se pak řeklo, jak má taková tabulka vypadat odkazem na mnoho dalších tříd, za kterými je schováno konkrétní další vzhled a chování:

    .tabulka-vypis { extends: .table, .table-dark, .table-striped, .table-responsive }
    

    Bohužel čisté CSS tohle neumí a CSS preprocessory to umí jen v omezené míře.

    1. Dor

      Re: V CSS chybí jedna úroveň abstrakce
      Podobně to dělám v LESS a funguje to dle očekávání. Zatím jediný zádrhel, na který jsem přišel, je to, že to může být matoucí, když se to ladí v prohlížeči. Není z toho moc poznat, co je kde definované.

    2. Vít Heřman

      Re: V CSS chybí jedna úroveň abstrakce
      Můžete naznačit, v čem jsou podle Vás preprocesory v tomto omezené? Podle mne spolehlivě tu úroveň abstrakce zajistí.

      Ale jinak jak píšete, lépe to moc nejde. A já bych jen dodal, že ani nemůže z principu jít. Buď redukujete duplicity, kladete důraz na čistou sémantiku a skončíte se složitou a obtížně udržovatelnou taxonomií nebo uděláte jednoduchou taxonomii, která má mnoho výhod, avšak může působit trochu jako prasárna.

      1. jirkakosek

        Re: V CSS chybí jedna úroveň abstrakce

        Můžete naznačit, v čem jsou podle Vás preprocesory v tomto omezené? Podle mne spolehlivě tu úroveň abstrakce zajistí.

        Nejsmutnější je, že jsou vůbec potřeba. Tím, že to není nativní funkce v CSS, preprocesory musí u mnoha deklarací přidávat další selektory a výsledné CSS pak může dost nakynout.

        1. Vít Heřman

          Re: V CSS chybí jedna úroveň abstrakce
          Jj, o tom žádná, že by bylo nejlepší, kdyby tohle umělo nativní CSS. Mne jen zajímalo „to něco“ , co podle Vás nejde udělat ani s preprocesory (a bez ohledu na výsledné CSS). Jednoduše mám pocit, že mixiny tento problém řeší, a to zcela. A třeba se mýlím a jen něco nevidím :-)

          1. Dor

            Re: V CSS chybí jedna úroveň abstrakce
            Ještě mě napadá další nevýhoda těch preprocesorů, že kdybych chtěl udělat .trida_elementu {.trida_s_barvou}, tak kdybych chtěl mít více variant souborů s .trida_s_barvou a ty podle potřeby proměňovat, tak mi nezbývá než sestavovat to pro každou variantu zvlášť nebo to sestavovat dynamicky v reálném čase. Takže kdyby to CSS uměly nativně, byl by to velký důvod k oslavě.

  5. Jan Pobořil

    Špatná čitelnost
    Tu špatnou čitelnost by řešilo pojmenování tříd bez zkratek – místo .d-b psát .display-block. Je to sice delší, ale bude rozdíl při kompresi podstatný?

  6. Martin

    Není možné se podělit o kód atomického css? :) Rád bych získal inspiraci a z minifkovaného souboru se to čte celkem blbě.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=21716