Polub bloga na fejsie!

Metodyki CSS #5 – Atomic CSS (ACSS)

17

To już piąta część mojej serii na temat metodyk CSS. Jest to jednocześnie ostatnia część tego cyklu. Myślę, że starczy nam tego CSS na jakiś czas… W sumie już ostatnim wpisem, na temat metodyki Atomic Design, mogłem już to wszystko zakończyć, stwierdziłem jednak, że warto będzie na koniec dorzucić kilka słów na temat Atomic CSS (w skrócie ACSS, będę tych nazw używać zamiennie), który po części oparty jest na metodyce, o której wspomniałem ostatnio.

Co to jest Atomic CSS

Myślę, iż można powiedzieć, że Atomic CSS opiera się na posiadaniu zestawu klas CSS, które są niezależne od treści i które są maksymalnie re-używalne. Sprowadza się to do tego, że w zasadzie wszystkie nasze style to klasy CSS posiadające po jednej parze „właściwość – wartość”.

Przykład

Dla lepszego zobrazowania o co chodzi, najlepiej chyba będzie posłużyć się przykładem. Powiedzmy, że posiadamy taki oto kod HTML:

Do tego zdefiniowaliśmy poniższe style:

Jak wspomniałem, w Atomic CSS style są „atomowe” czyli maksymalnie re-używalne i najczęściej „jedno-linijkowe”. Dlatego też po przejściu na ACSS, powyższy przykład mógłby wyglądać na przykład następująco:

Wypadałoby jeszcze pokazać definicje powyższych klas CSS:

Abstrahując od nazewnictwa klas, w powyższym przykładzie dobrze widać, na czym polega „atomizacja” stylów CSS. Każdy z nich odpowiada za jedno tylko ustawienie. Dzięki temu klasy te są zupełnie niezależne od treści jakiej dotyczą.

W przykładzie, w którym nie użyłem klas jeszcze ACSS widać, że zarówno w klasie container jak i stylach dla elementu p mamy powtórzenie ustawienia padding: 10px. Dzięki temu, że podzieliliśmy style na „atomowe” klasy, nie mamy już tej redundancji kodu. Zamiast tego mamy teraz po prostu jedna klasę pd-10, którą re-używamy wszędzie tam, gdzie potrzebujemy ustawić wartość właściwości padding na 10px.

Nie jest też absolutną regułą, że każda klasa musi koniecznie mieć tylko jedno ustawienie stylu. Czasem może zajść potrzeba nadania większej liczy ustawień per klasa. Należy jedynie pamiętać o zachowaniu jej „atomowości” czyli, że ma ona być zupełnie niezależna od kontekstu w jakim się jej używa.

Nazewnictwo klas

W powyższych przykładach użyłem nazw klas, które sam wymyśliłem. W Atomic CSS w sumie nie ma jakiegoś szczególnego zalecenia jeśli chodzi o konwencje nazewnicze.

Z tego co przeglądałem sieć Internet przygotowując ten artykuł zauważyłem, że zwykle nie stosuje się nazw w stylu mg-0 gdzie md oznacza margin a 0 odpowiada wartości 0px. Wydaje się, że lepszym podejściem jest zdefiniowanie globalnych zmiennych odpowiadających poszczególnym wielkościom i stosowanie nazw bardziej opisowych. Dla przykładu, z użyciem Sass mogłoby to wyglądać tak jak poniżej:

Częstym podejściem do nazewnictwa klas „atomowych” jest też inspirowanie się popularnym ostatnio narzędziem Emmet. Nie będą wdawać się w szczegóły tego narzędzia – można o tym przeczytać i obejrzeć w innych serwisach. Napiszę tylko, że pozwala ono znacznie usprawnić proces „klepania” kodu HTML jak i CSS – wystarczy napisać w edytorze odpowiednią skrótową nazwę (lub ich cały ciąg), a Emmet na tej podstawie generuje kod. I właśnie te nazwy skrótów Emmeta są inspiracją do nazywania klas CSS tworzonych w oparciu o ACSS.

Atomizer

W oparciu o zasady tworzenia klas Atomic CSS powstał tez projekt acss.io oraz narzędzie atomizer. Pierwsze z nich definiuje zestaw predefiniowanych klas inspirowanych właśnie Emmetem. Dzięki temu drugiemu możliwe jest wykorzystywanie tychże „atomowych” klas w sposób funkcyjny… zresztą chyba lepiej pokazać to na przykładzie (wprost ze strony projektu):

Jak widzisz, dzięki użyciu atomizera możemy wykorzystywać predefiniowane klasy jak funkcje, które nadają odpowiednim właściwościom CSS wartość przekazaną jako parametr. Jeśli Cię to zaciekawiło to być może warto zapoznać się z tym projektem – jest ono dostępne oczywiście, m.in. jako plugin dla Gulpa czy loader dla webpacka.

ACSS – podsumowanie

To tyle jeśli chodzi o Atomic CSS jak i o moją serię o metodykach CSS. Muszę przyznać, że pracując nad tymi wpisami sam sporo się nauczyłem – nie wszystko co opisałem było mi wcześniej dobrze znane. Mam nadzieję, że i Tobie ta wiedza się przyda. Nawet jeśli nie będziesz wykorzystywać w praktyce wszystkich tych podejść to myślę, że warto mieć świadomość o ich istnieniu oraz jakie są ich największe wady i zalety.


Wpis ten jest częścią serii na temat metodyk CSS – poniżej linki do wszystkich części serii:

REACT, REDUX, REACT-ROUTER - KURSY ON-LINE

Chcesz od podstaw poznać tajniki React, Redux oraz react-router? Zapraszam do moich szkoleń on-line:

Przejdź do szkoleń
  • Już koniec? Jeszcze jeden: http://ecss.io/ 😉

    A tak bardziej serio: ACSS mnie odrzuca z bardzo prostego powodu: robimy style inline bez stylów inline. Przecież to jest tight coupling HTML-a z CSS-em w najgorszym możliwym wydaniu. Tracimy wszelkie informacje o strukturze strony, zamiast .page__main dostajemy .d(block).P(20px).BG(blue) itd. W tym momencie cały kod HTML jest ukierunkowany wyłącznie na prezentację. Źle się dzieje IMO jeśli, by zmienić wygląd strony, modyfikujemy HTML (!!!).

    Natomiast gdyby z ACSS zrobić ASCSS i traktować wszystkie te atomy jako mixiny do budowania większych struktur:
    .page__main {
    @include BG(blue);
    @include P(20px);
    @include d(block);
    }
    o, to wygląda za to _perfekcyjnie_.

    ASCSS – jedna literka, a ile zmienia 😉

    • Koniec! Miała być mini-seria, a aż 5 postów powstało… Pierwotnie planowałem tylko OOCSS, BEM i SMACSS…
      Co do ACSS to zgadzam się w pełni z tym co napisałeś. Jeśli natomiast chodzi o ASCSS to skoro to są skróty z Emmeta to może po prostu go używać? 😉

  • Marcin Kopeć

    Witam,
    którą metodykę polecacie i dlaczego?

    • Klonos

      Dla mnie sprawdza się BEM. SMACSS zakłada zagnieżdżenie elementów w stylach css, zdecydowanie wolę mieć jeden poziom klas w połączeniu z less czy sass masz czyste i czytelne style. Dodatkowo warto budować html i nazwy klas myśląc o maksymalnej reużywalności kodu, czyli kłania się atomic design.

      • Marcin Kopeć

        No tak jeśli pozwalają Tobie nie zagnieżdzać to masz super.
        Mój pracodawca tego wymaga i muszę robić zagnieżdżenia nawet w projektach na WP.
        Im więcej czytam na temat metodyk to zauważam że w jednej książki są negowane wytyczne z drugiej a w trzeciej negują…..itp. itd.
        A tyle się mówi o standaryzacji….

        • Większość metodyk ma tę samą mantrę: płaska specyficzność, co sprowadza się w większości przypadków do operowania wyłącznie klasami, bez zagnieżdżania.

          Zresztą frontend nigdy nie umiał w standaryzację 😉

        • Klonos

          im bardziej płasko tym większe szanse na reużywalność poszczególnych atomów czy organizmów. Lib nawet przemieszczenie ich w ramach komponentu – przy żywych projektach to ułatwia pracę.

          Z ciekawości, czym pracodawca motywuje zagnieżdżanie? 🙂

          • Marcin Kopeć

            1. Style zagnieżdżone są ‚odpalane’ tylko dla określonej struktury drzewa DOM a nie „globalnie”. Jedzie sobie koleś klasami i nie musi się martwić że coś mu się gdzieś w innej części serwisu nadpisze lub wczyta. Częściowo podzielam taką koncepcję, przy założeniu że nie zagnieżdża się ‚za głęboko’ ponieważ potem więcej roboty jest przy próbie ponownego użycia kodu w innej części serwisu(reusing)

            2. „My tak w tej firmie robimy więc ty tak musisz robić”

          • > Style zagnieżdżone są ‚odpalane’ tylko dla określonej struktury drzewa DOM a nie „globalnie”.

            No popatrz, a w FB całego Reacta wymyślili, żeby to osiągnąć 😀

            Problem polega na tym, że w przypadku np. BEM też nie ma obawy, że coś się nam nadpisze, bo nad tym czuwa sztywna konwencja nazewnicza. A jak już chcemy naprawdę lokalnych stylów, :scope w CSS i Shadow DOM.

        • Przemysław Szelenberger

          Widzę, że przydałby się post o specyficzności selektorów i dlaczego warto mieć je bliskie 0,0,1,0. Do tego użycie narzędzia https://github.com/katiefenn/parker może pokazać ciekawe statystyki dotyczące specyficzności selektorów w projekcie.

          • Marcin Kopeć

            Bardzo ciekawe narzędzie. Obadam prędzej czy później. Faktycznie przydało by się omówić tą kwestię. Ja do tej pory korzystałem z walidatorów W3C i Google WebMaster gdy był czas i budżet na takie analizy.

  • Maciej Cąderek

    Zabrakło chyba najsensowniejszej obecnie opcji – CSS Modules (jak ktoś się bawi w reacta to fajną opcją są jeszcze styled-components).

    • Z tym, że CSSM nie są żadną metodologią, a hackiem, który zezwala na pisanie „lokalnych” stylów i aplikowanie ich z poziomu CSS-a. W takim wypadku wolę już użyć zewnętrznego arkusza i prawdziwie lokalnych stylów wewnątrz Shadow DOM.

  • Warte uwagi moim zdaniem metodyki, które warto znać to ITCSS i BEMIT autorstwa H. Robertsa. Podsuwam jako propozycję pociągnięcia serii 🙂

  • Przy okazji końca serii chciałbym poruszyć jedną kwestię. W sieci często spotykam się z argumentem, że opisane metodologie tylko zaśmiecają html niepotrzebnymi stylami CSS. Czuję, że rozwiązanie tego problemu leży gdzieś po środku (należy dostosować styl pisania CSS do wielkości projektu), jednak chciałbym dowiedzieć się co sądzicie na ten temat.

    • Z racji, że korzystam głównie z BEM, odpowiem na jego przykładzie. Tak, na samym początku może się wydawać, że to książkowy przykład classitisu i że brudzimy HTML. Niemniej ten argument da się utrzymać tylko wówczas, gdy uznajemy BEM wyłącznie za konwencję nazewniczą. Jeśli bowiem przejdziemy do myślenia o BEM jako architekturze, wówczas zrozumiemy, że jest po prostu warstwą abstrakcji, która pozwala nam nie myśleć o HTML-u i CSS-ie, ale o komponentach i ich częściach. Zamast diva mamy comment-box itd. To otwiera na ciekawą drogę do polepszenia developmentu (każdy blok jest odizolowany, ma dedykowane style i folder, można go przenosić pomiędzy projektami i testować w odosobnieniu).

  • przecież ta metodyka to jest zamaskowany Style in line 🙂

Google Analytics Alternative