Komentarze do: Zarządzanie kaskadowymi arkuszami stylów, czyli CSS w praktyce

Autor: Artur Rychlewicz

Artur Rychlewicz — Thu, 06 Mar 2014 21:23:00 +0000

W odpowiedzi do Comandeer. Tak, to nadal jest kontekstowość, nawet BEM zachowuje kontekstowość, co niestety mnie boli. .nav .link .active jest już nie zależne od kontekstu, niestety nie znam jeszcze fw, który oferowałby taką strukturę.

Autor: Comandeer

Comandeer — Thu, 06 Mar 2014 21:16:00 +0000

W odpowiedzi do Artur Rychlewicz. >Kontekstowość jest wtedy, gdy używasz coś a'la #jakiesID a.active, kiedy chcemy porzucić kontekstowość to mamy .s-10 .red .m-25. Raczej miałem na myśli .Nav .Nav-link--active - jak dla mnie kontekstowość w takim przypadku jest zachowana. Poza tym z doświadczenia wiem, że po pewnym czasie taki zagnieżdżony kod jest nie tylko niewydajny, ale powoduje problemy ze specyficznością selektorów, dlatego optuję za klasami.

Autor: Artur Rychlewicz

Artur Rychlewicz — Thu, 06 Mar 2014 21:12:00 +0000

W odpowiedzi do Comandeer. Co do nadmiarowości kodu, CSS, itd. to już jest sprawa frameworka. Przez "dobre" frameworki miałem na myśli poprawnie napisane (przez co mam na myśli, nie wywalają 1224236 errorów do konsoli). Czy Tobie to pasuje czy nie to już Twoja sprawa, właśnie dlatego mamy do dyspozycji wiele frameworków, ja sam nie jestem zwolennikiem Bootstrapa, ale z kolei lubię Foundation i Pure, które z kolei przydaje się w bardzo prostych projektach. ID. Hmm. Właśnie pomieszałeś ;) Kontekstowość jest wtedy, gdy używasz coś a'la #jakiesID a.active, kiedy chcemy porzucić kontekstowość to mamy .s-10 .red .m-25. Używanie ID jest dobre (nie tylko w małych projekach) kiedy mamy bardzo dużo zagnieżdżonego kodu (np. div nav div right .main-nav ul li a.active) i zamiast robić bardzo długi łańcuszek skracamy to do np. #main-nav-right a.active. Tutaj jeszcze wyjaśnię - żeby nie było wątpliwości - ID należy używać TYLKO, gdy wie się, że dany element nigdy nie powtórzy się dwa lub więcej razy. To dobry sposób na zaznaczenie głównego menu, search boxa, itd. No i oczywiście tak długo, jak ktoś pisze kontekstowo - gdy ktoś leci na samych klasach, używanie ID jako selektorów CSS mija się z celem. Racja, zwracam honor Autorowi, mój błąd ;)

Autor: Mr.Mr

Mr.Mr — Thu, 06 Mar 2014 21:07:00 +0000

W odpowiedzi do Artur Rychlewicz. To ja też odniosę się po kolei ;) 1. Frameworki - nie chodzi o to, że 'coś nie działa', ale o to, że używanie frameworka jako gwarancji dla tego, że będziemy mieć przejrzysty arkusz styli jest błędnym założeniem. I tak - framework może być czasami utrudnieniem przy pisaniu CSS ponieważ nie zawsze jest w ogóle potrzebny (wiele osób używa frameworków jako drogi na skróty przez proces deweloperski), a po drugie przy dużych projektach kończy się to najczęściej tak, że dopisujemy sobie drugi gigantyczny plik CSS, w którym nadpisujemy rozwiązania frameworka co może się mijać z celem. 2. BEM, OOCSS, SMACSS, itd. - korzystaj z czego Ci się tam podoba. Jeśli dla Ciebie LESS czy SASS to odpowiedź na problemy, które poruszyłem to super - o tym pisałem właśnie - nie ma jednej drogi ;) 3. ID jest be - Jakoś się nie wstydzę ;) Mogę ewentualnie zgodzić się z tym co pisał Comandeer odnośnie JS i ID. W CSS moim zdaniem to jest element zbędny. 4. Szalone selektory - Ten przykład był absurdalny nie bez powodu. Widzę, że wziąleś go sobie bardzo do serca, ale chyba niepotrzebnie ;) 5. No właśnie tak odnośnie 'znania się na rzeczy' to to co opisałeś działa odwrotnie. Nie zrozum tego jako krytykę ;) Dzięki za komenatrz.

Autor: Comandeer

Comandeer — Thu, 06 Mar 2014 20:20:00 +0000

W odpowiedzi do Artur Rychlewicz. >Jeśli jest coś, co w dobrze napisanym frameworku (Foundation, Bootstrap, Skelton, Semantic, itd.) nie działa tak jak powinno działać, to uwierz mi, jest to Twoja wina. Nie zgodzę się, że Bootstrap czy Semantic są dobrze napisanymi frameworkami. Pierwszy cierpi na pomieszanie BEM z innymi selektorami a drugi na przerost formy nad treścią (gdzieś już tutaj się w komentarzach na ten temat wypowiadałem). Pracowałem trochę z Bootstrapem i już mnie krew zalewała, bo nie dość, że nadmiarowy HTML był jakąś kpiną, to dodatkowo musiałem się użerać ze specyficznością selektorów (bo nagle zamiast klasy, ktoś zastosował selektor dziecka, albo radośnie sobie wstawił !important). Co do Semantic - leży wydajnościowo: jest jakieś 3 razy wolniejszy od analogicznego rozwiązania BEM-owego >ID jest be - tutaj znów zależy jak piszemy kod CSS, jeżeli piszemy kontekstowo to ID jest jak najbardziej pożądane! id zabija specyficznością, dlatego BEM walcem po tym przejeżdża. Klasami też można uzyskać kontekstowość. Tak naprawdę id przydaje się tylko w małych projektach, gdzie mamy pewność, że poszczególne moduły się nie powtórzą. Osobiście stosuję regułę: klasa - CSS, id - JS. Pozwala to w prosty sposób odróżnić funkcję elementu od jego wyglądu. >Zauważ, że CSSOM musi w tym miejscu najpierw pobrać wszystkie tagi z klasą a, z tym wybrać wszystkie z klasą b, a później c. Następnie musi wybrać wszystkie ul z klasą link, które są bezpośrednim dzieckiem klasy c, na końcu musi pobrać wszystkie input i wybrać z nich te z atrybutem type równym text. Jest właśnie dokładnie na odwrót ;) Selektory czytane są od prawej do lewej, zatem przeglądarka zaczyna od pola tekstowego a później leci po jego rodzicach.

Autor: Comandeer

Comandeer — Thu, 06 Mar 2014 20:06:00 +0000

>Pytanie jest jednak proste – czy rzeczywiście używanie frameworka jest rozwiązaniem? Moim zdaniem nie.
To zależy jakiego i do czego. Bootstrap to po prostu jakaś pomyłka. Z jednej strony dostajemy prawie BEM-owe selektory a z drugiej kwiatki typu .tabs > li, gdzie szlag trafia specyficzność selektorów.
Prawdziwy framework CSS-owy? Jak na razie wskazałbym na inuita, który jest naprawdę frameworkiem (nie narzuca wyglądu).
No i oczywiście framework pure-CSS też nie bardzo pasuje, bo dostajemy gotowego klocka, którego trudno ruszyć (stąd de facto każdy framework korzysta z preprocesorów).

>Tutaj moja rada jest prosta – szukaj własnych rozwiązań korzystając z doświadczeń innych.
Powiem tak: ostatecznie i tak każde rozwiązanie będzie dążyć do czegoś w rodzaju BEM, gdzie następuje maksymalne spłaszczenie hierarchii elementów do prostych zależności między klasami. Zabawy z dziedziczeniem i kaskadowością (czyli „naturalny OOCSS”, jakbym to nazwał) sprawdzają się dla prostych projektów. I tak, wiem, że od dawna uważałem BEM za zło, ale przy większych projektach jest to najsensowniejsze i najszybsze rozwiązanie.

>Uszczegółowiając to co pisałem powyżej radziłbym od samego początku planować arkusz stylów w sposób modułowy.
Ale to co pokazałeś nie ma nic wspólnego z modułami, ani tym bardziej z BEM. Jak już, to raczej: .Sidebar i .Sidebar–top-box. Teraz bardziej widać przynależność odpowiednich rzeczy do odpowiednich modułów

>Nie uważam żeby CSS Lint był odpowiedzią na wszystko, a co więcej często jego 'rady’ są trochę mało zyciowe, ale nie da się ukryć, że uczy on dobrych nawyków.
Standardy wewnątrzorganizacyjne > CSS Lint. Jak dla mnie nie ma sensu używać tego narzędzia ;) Jeśli chodzi o CSS, wystarczy wiedzieć czy składnia jest OK (a to i tak zrobi nam LESS/SASS/Stylus/Absurd.js/Whateva)

>Krótko i na temat – nie stosuj, chyba że jest to na serio do czegoś niezbędne.
Tu trza by dopowiedzieć: nie stosuj w arkuszach stylów. id jako hook dla JS jest z kolei genialne

>Trzeba jednak pamiętać o tym by przed 'deploy’em’ owy kod złączyć w jednym pliku i pewnie najlepiej skompresować
grunt.js -> przepuszczasz przez preprocesor, następnie dajesz to Autoprefixerowi i na koniec przywalasz kompresję choćby przez CSSO. Po całym procesie grunt.js jeszcze Ci spokojnie commita do repo zrobi i zuploaduje całość na produkcję a ty w tym czasie wypijesz kawkę ;)

Autor: Artur Rychlewicz

Artur Rychlewicz — Thu, 06 Mar 2014 15:05:00 +0000

Moje spostrzeżenie po przeczytaniu tego artykułu jest proste – autor, z całym szacunkiem, nie wie o czym pisze. Jeżeli ktoś faktycznie rozumie CSS to jest w stanie poradzić sobie z wszystkimi podanymi tutaj radami bez najmniejszego problemu. Jest wiele „technik” pisania „dobrego” CSS. Ale, żeby nie było hejterstwa, opiszę po kolei co wg mnie jest złe.
Używanie frameworków. Tutaj ciężko po części się nie zgodzić z tym co napisał Autor, jednakże pisanie o tym, że framework nadkłada pracy jest kompletną bzdurą. Jeśli jest coś, co w dobrze napisanym frameworku (Foundation, Bootstrap, Skelton, Semantic, itd.) nie działa tak jak powinno działać, to uwierz mi, jest to Twoja wina. Każdy front-end framework jest napisany w taki sposób, by skrócić pracę, i tak, zgadzam się, że trzeba dopisać własne części, bo przecież chcemy, żeby nasza strona wyglądała inaczej, ale napisanie tego samego kodu bez frameworka to kolejne, w najlepszym wypadku, kilkadziesiąt minut pracy.
BEM, OOCSS, SMACSS, itd. – kolejny, wybacz, że tak to nazwę, absurd. Znalezienie własnego, lepszego sposobu jest bardzo nikłe. Dlaczego korzystamy z MVC lub podobnych architektur? Dlatego, że one zostały już sprawdzone, przetestowane i w większości przypadków, sprawdzają się nadzwyczaj dobrze, dlatego też w/w techniki są dobre. Nie czujesz się z nimi komfortowo – OK, możesz budować strony w jaki sposób tylko chcesz, ale pamiętaj, że koniec końców każdy developer (a szczególnie front-end developer) ma jeszcze jedno zadanie – Twoja strona, czy też aplikacja, którą budujesz, musi być szybka, i najczęściej mała. Jeżeli niekontekstowy model budowania aplikacji pozwala Ci zaoszczędzić kilka MB, a dodatkowo sam kod CSS jest bardzo czytelny, to dlaczego z niego nie korzystać? Tutaj ponownie odwołuje się do „czytelności” kodu, jeśli kod nie jest czytelny, to jest to Twoja wina.
DRY – SASS/LESS. EOT.
Szalone selektory – tutaj zgadzam się po części, jednakże ten zły przykład jest naprawdę zły ;) .Site #Sidebar > ul.Links li a.Active
po co dawać id w środku selektoru? Element o danym ID może wystąpić tylko raz w drzewie dokumentu. Po co dawać ul.Links li? ul.Links a.Active daje to samo, a inna opcja wystąpić nie może, bo bezpośrednim dzieckiem ul zawsze będzie li.
Zlintuj się – tutaj ciężko się spierać, bo to naprawdę indywidualna sprawa. Ja mam w nawyku dzielenia właściwości na części, których dotyczą. Innymi słowy, najpierw znajduje się width, height, padding, margin, itd., a dopiero póżniej znajdują się właściwiości odpowiedzialne za np. formatowanie tekstu. Pomiędzy kolejnymi „częściami” znajduje się dodatkowa wolna linia.
ID jest be – tutaj znów zależy jak piszemy kod CSS, jeżeli piszemy kontekstowo to ID jest jak najbardziej pożądane! Po pierwsze, ID jest szybsze, po drugie, ID zaznacza mniejszą ilość selektorów. Wstydziłbyś się coś takiego pisać :( Jeżeli nie piszemy kontekstowo to ID jak najbardziej można usuwać, ale po Twoim stylu już widzę, że piszesz kontekstowo…
Rozdzielenie arkuszy – zgadzam się jak najbardziej, ale ponownie, dobrze napisany kod CSS jest napisany w taki sposób, że selektor A nigdy nie nadpisze selektora B i odwrotnie. Wyjątkiem od tego jest model responsywny, gdzie najczęściej pisze się teraz mobile-first. Do tego dodam, że każde łącznie, kompresowanie, i inne ręczne robótki powinny zostać zautomatyzowane – tutaj polecam node.js i Grunt.
Efektywne arkusze stylów – tutaj po części po raz kolejny już się nie zgadzam. Selektory są ważne, szczególnie gdy buduje się bloczki takie jak .a .b .c > ul.link input[type=text]. Zauważ, że CSSOM musi w tym miejscu najpierw pobrać wszystkie tagi z klasą a, z tym wybrać wszystkie z klasą b, a później c. Następnie musi wybrać wszystkie ul z klasą link, które są bezpośrednim dzieckiem klasy c, na końcu musi pobrać wszystkie input i wybrać z nich te z atrybutem type równym text. Nie wmówisz mi, że jest to tak samo szybkie jak ul.link input.important. Inną ważną rzeczą jest to, że renderowanie odbywa się, gdy CSSOM obliczy wartości, tak samo działa DOM w JS.
Nie zrozum tego jako krytykę, fajnie, że dzielisz się swoimi umiejętnościami, ale czasami lepiej jest przemyśleć jeszcze raz swoje zdanie.
Pozdrawiam

Autor: Mr.Mr

Mr.Mr — Thu, 06 Mar 2014 08:30:00 +0000

W odpowiedzi do Piotr Nalepa. Odpowiadając: 1. To jest sposób zapisu zbliżony do BEM, ale nie do końca BEM'owy - idea jest podobna, a nie wszystko. Ty podajesz taki sposób bardziej odpowiadający założeniom BEM, chociaż też nie do końca bo tam są te nazwy podstawowe i modyfikatory. 2. CSS Lint ma wiele funkcji i tutaj się zgodzę, że akurat 'układanie' deklaracji to taki 'nice to have', ale wymienianie wszystkiego mija się z celem. Myślę, że lepiej żeby każdy sobie sam wyciągnął z tego co będzie mu potrzebne. 3. Dzięki za uzupełnienie.

Autor: Michał Załęcki

Michał Załęcki — Wed, 05 Mar 2014 22:28:00 +0000

Ja już na CSS patrze prawię jak na binarke. Zawsze skompresowana, bez białych znaków i cała w jednym pliku, a w trakcie tworzenia rozbita na 3-5 katalogów i osobne pliki. SASS/LESS rules! Co do rozmieszczania samych właściwości w selektorze to alfabetycznie. Frameworki CSS udostępniają zmienne do konfiguracji wiec sprawa jest dziecinnie prosta.

Autor: Piotr Nalepa

Piotr Nalepa — Wed, 05 Mar 2014 22:16:00 +0000

3 rzeczy które zauważyłem w tym artykule po szybkim przejrzeniu:
1). .Sidebar i .SidebarTopBox nie są ze sobą w żaden sposób powiązane. Poiwnny być te nazwy zupełnie inaczej pisane (przede wszystkim z małej litery nazwy klas!): .sidebar i .sidebar .top-box
2). zadaniem CSS Linta nie jest łądne uporządkowanie własności CSS, tylko wskazanie własności sprzecznych ze sobą i wskazanie nieścisłości w kodzie CSS. Sortowanie własności to tylko nice-to-have feature.
3). Piszesz o rozdzielaniu arkuszy CSS, to bardzo fajnie. Dobra praktyka. Lecz możesz wspomnieć też o tym, aby te CSSy łatwo łączyć ze sobą w jedną całość za pomocą automatów takich jak Grunt.js – tu jest artykuł o tym, jak tego używać: http://blog.piotrnalepa.pl/2013/12/14/js-grunt-to-grunt-js-czyli-o-tym-jak-zautomatyzowac-prace-webdevelopera/