Kolejne, już czwarte, spotkanie Bydgoszcz Web Development Meetup za nami. Miałem przyjemność poprowadzić jedną z trzech prezentacji, która dotyczyła dobrych praktyk CSS, BEM, OOCSS na przykładzie inuit.css. Obok mnie prezentacje przeprowadzili Sebastian Małyska (Przychodzi tester do developera) oraz Michał Kowalkowski (O backwi.re i prowadzeniu startupu w Chinach). Na zakończenie Lightning Talks, podczas których m. in. pośmiałem się (braku)logiki operatorów porównania w JavaScript przy operacjach na
i
null, Paulina Rhone zaprosiła nas na spotkania Geek Girls Carrots oraz opowiedziała o tej organizacji. Jakub Czaplicki, twórca popularnej aplikacji Sprawdź lekarza opowiedział o ciekawej historii swojej aplikacji.
Prezentacja
Prezentacja dotyczy dobrych praktyk CSS, BEM i OOCSS.
Tagi: BEM • BWDM • CSS3 • SCSS
IMO w przypadku używania BEM coś takiego jak selektory stanów i selektory do pracy z JS są całkowicie redundantne. Obydwa można zastąpić rozsądnie zastosowanymi Modifiers. Tutaj bardzo pomaga praca z tzw. BEM tree (coś wspaniałego!), która szybko uzmysławia, że BEM to nie tylko konwencja w CSS, ale potężna architektura aplikacji. Polecam jako lekturkę http://www.smashingmagazine.com/2014/07/17/bem-methodology-for-small-projects/
Co do OOCSS – wydaje mi się akurat, że przykład w BEM to nie to ;) BEM bowiem zabija natywną obiektywność CSS (zarówno kaskadowość selektorów, jak i dziedziczenie), wprowadzając płaską hierarchię klas i polimorfizm (aka modifiers, co właśnie widać na Twoim przykładzie). Dla mnie OOCSS to bardziej to, co przedstawił logeen: http://www.kurshtml.edu.pl/css/css_zorientowane_obiektowo,dobre_praktyki.html
Jeśli używamy określenia OOCSS w stosunku do BEM, należy uściślić, że chodzi nam tak naprawdę o przeniesienie obiektowości z CSS na poziom abstrakcyjnego modelu BEM.
Co do rem/em: http://css-tricks.com/rems-ems/ – bodaj najlepszy pomysł na modułowy CSS jaki widziałem. Genialne uzupełnienie dla BEM.
Co do id w CSS i jego 255 razy silniejszego działania: błąd w implementacji ;) Stara Opera nie miała tego buga (AFAIR zapisywali to w 64-bitowej zmiennej, zamiast w 32-bitowej jak cała reszta).
Co do preprocesora: pracowałem na LESS, ale pozwalał na zbyt mało. Przeszedłem na SASS-a, ale wciąż pozwalał na zbyt mało. Teraz siedzę na Stylusie i dalej mnie drażni, że tak mało w nim można… ;) Chyba dla takich jak ja zostaje Absurd.js
Czytałem ten artykuł ze smashing, nawet zapodałem go pod naszym artykułem o BEM. Moim zdaniem tekst ze smashing mag nie był bardzo specjalnie treściwy…
Nie był, ale ładnie wprowadza właśnie pojęcie BEM Tree ;)
W niedalekiej przyszłości opublikuję demo do prezentacji.
> IMO w przypadku używania BEM coś takiego jak selektory stanów i selektory do pracy z JS są całkowicie redundantne.
Zależy. Przy stronkach wizytówkach, możliwe. Przeciwnie przy dużych projektach, taka separacja oszczędza potem wiele czasu.
> Co do rem/em: http://css-tricks.com/rems-ems… – bodaj najlepszy pomysł na modułowy CSS jaki widziałem. Genialne uzupełnienie dla BEM.
Fajne przy mniejszych projektach, przy większych siłą rzeczy kończy się na nadaniu wielu elementom i tak sztywnych wartości, bo niektóre elementy interfejsu po prostu muszą mieć określone proporcje i wymiary.
> Przeszedłem na SASS-a, ale wciąż pozwalał na zbyt mało.
Zbyt mało? To chyba bardzo starą dokumentacje czytałeś. Czego nie mogłeś zrobić w SCSS?
>Przeciwnie przy dużych projektach, taka separacja oszczędza potem wiele czasu.
Powiedziałbym coś zupełnie przeciwnego. Przy pełnym używaniu BEM tree, nigdy nie zajdzie potrzeby tego typu działań. Tym bardziej, że semantyczny JS oparty na BEM jest po prostu łatwiejszy do ogarnięcia.
>Fajne przy mniejszych projektach, przy większych siłą rzeczy kończy się na nadaniu wielu elementom i tak sztywnych wartości, bo niektóre elementy interfejsu po prostu muszą mieć określone proporcje i wymiary.
Przy mniejszych projektach również przecież. Oczywiście nie ma sensu wszystkiego trzymać w rem/em, ale na pewno wszystko, co się da, lepiej w tym mieć
>Czego nie mogłeś zrobić w SCSS?
System modułów z configiem ad hoc, redefinicja mixins, definiowanie mixins po ich wywołaniu (czyli hoisting)… dużo by wymieniać. W Stylusie udało się to dorobić tylko i wyłącznie dlatego, że po prostu udostępnia parser JS…
Tylko, że przy mniejszych łatwo nad tym zapanować i nie ma tak czasochłonnego procesu testowania.
Co do modułów to są przecierz w SASS (gemy), plik konfiguracyjny rownież z opcjami od includowania po ustawienia dokładności przybliżeń przy obliczeniach. To z tą niezależnością od języka – dla mnie argument na siłę podobnie z redefinicją wstawek. Debugowanie kodu, którego wynik zależy od jego umieszczenia w arkuszu… coż, do przyjemnych pewnie nie należy.
Co do zdalnego konfigu to jakoś na szybko nie widzę płynących z niego korzyści, których nie dałoby się zrealizować w bardziej naturalny sposób.
Jaka jest wydajność takiego rozwiazania przy 16 tyś. linii CSS? Bo kompilacja tego na PC zajmuje nawet ponad kilkanaście sekund (jest cache, więc zależy gdzie nastąpiły zamiany).
>Tylko, że przy mniejszych łatwo nad tym zapanować i nie ma tak czasochłonnego procesu testowania.
Płotkę też łatwiej zabić niż wieloryba ;) Przy odpowiednio zautomatyzowanych unit testach CSS-a robi się to samo (np Cucumber + phantom.js + referencyjny screenshot). Oczywiście takie testy łatwiej przeprowadzać na niezależnych modułach (i tutaj znowu dobrze się sprawdzają niezależne moduły BEM).
>Co do modułów to są przecierz w SASS (gemy), plik konfiguracyjny rownież z opcjami od includowania po ustawienia dokładności przybliżeń przy obliczeniach.
To nie jest rozwiązanie dobre do wszystkiego – ma bardzo specyficzny zasięg stosowania. Modułem jest bazowy selektor rozszerzany przy pomocy nadpisywalnego configu (coś jak !default w SCSS) i warunkowych mixins (mogą, ale nie muszą być zadeklarowane). W LESS dało się to osiągnąć przy pomocy hoistingu mixins, w Stylusie tę rolę przejął zewnętrzny plugin wprowadzający prawdziwą modularność. W SASS było ten problem najtrudniej rozwiązać ;)
>To z tą niezależnością od języka – dla mnie argument na siłę podobnie z redefinicją wstawek
Masz cały system w C++ – napiszesz do niego dodatek w Javie?
>Debugowanie kodu, którego wynik zależy od miejsca jego umieszczenia w arkuszu… coż, do przyjemnych pewnie nie należy.
Hoisting jest przewidywalny przecież. Znasz JS = rozumiesz hoisting.
>Co do zdalnego konfigu to jakoś na szybko nie widzę płynących z niego korzyści
Jeszcze raz powiem, że to system w gruncie rzeczy przypominający !default w SCSS
>Jaka jest wydajność takiego rozwiazania przy 16 tyś. linii CSS?
Dobra. Jeśli głównym zmartwieniem jest optymalizacja build toola, to musicie mieć naprawdę wydajny produkt ;)
>Jeżeli faktycznie to takie dobre rozwiązanie to chętnie je wypróbuję.
Jest cholernie profilowane, więc ma bardzo wąskie zastosowanie. Niemniej w tym, do czego zostało stworzone, jest o wiele lepsze niźli mechanizmy oferowane out of box we wszystkich preprocesorach.
Świetna prezentacja Michał ;) Tu jest filmik z prezentacji na żywo: http://youtu.be/h1m5GC1-rtk
Dzięki :)
Istnieje jakiś agregator takich spotkań z różnych miast? Chętnie poszłabym na coś podobnego w moim mieście, albo chociaż w południowej części kraju, bo jak się dowiaduję o imprezach to zazwyczaj z relacji już po danym wydarzeniu.
http://crossweb.pl/
nie wiem czy mają tam wszystkie wydarzenia, ale na pewno dużo