Mimo że dzień w dzień mamy do czynienia z Kaskadowymi Arkuszami Stylów radzenie sobie z kaskadowością, dziedziczeniem, selektorami i problemami przeglądarkowymi może być czasami trudne. Rozbudowane pliki CSS potrafią przyprawić o zawrót głowy, a ich edycja bez użycia narzędzi deweloperskich wydaje się czasami praktycznie niemożliwa. Dlatego jako twórcy witryn internetowych często zadajemy sobie pytanie o to jak budować arkusze stylów aby były jak najprostsze w edycji i późniejszej rozbudowie. Można się spytać dlaczego o tym myśleć, ale każdy kto zna realia wie, iż każda strona internetowa to tak na prawdę niekończący się projekt zmian, rozbudowy, przebudowy i poprawek. Tylko budując sensowne arkusze CSS jesteśmy w stanie nie zwariować w pracy :) Aby pomóc Wam w zachowaniu zdrowia psychicznego przygotowaliśmy kilka porad i wskazówek, które jak mamy nadzieję pomogą Wam w codziennych zadaniach.
Używaj frameworków?
Uff… Temat rzeka i to do tego pełna krokodyli i wodnych rozbójników. Frameworki CSS są rzeczywiście pierwszym rozwiązaniem, które przychodzi wielu ludziom do głowy, gdy słyszą pytanie o problem pt. „Jak zbudować przejrzysty arkusz styli”. Pytanie jest jednak proste – czy rzeczywiście używanie frameworka jest rozwiązaniem? Moim zdaniem nie. Problem z frameworkami jest taki, że często same posiadają wiele mankamentów, których usuwanie mija się z celem, ponieważ zamiast skracać proces deweloperski jeszcze go wydłuża. Drugi problem polega na tym, że niektóre cechy i rozwiązania danego frameworka mogą być wadami w pewnym kontekście. Chodzi o sytuacje gdy ogólnie zachwalane rozwiązanie w przypadku naszego projektu staje się bardziej przeszkodą i uporczywym problemem. Tutaj znowu usuwanie takiego mankamentu może być pozbawione sensu.
Jeśli nigdy nie było Ci dane używać jakiegoś frameworka wielokrotnie w różnych projektach możesz nigdy nie zauważyć tego o czym pisałem powyżej. Może to i lepiej :) Jednak nawet jeśli nigdy nie spotkasz się z problemami, o których piszę wyżej są inne, o których powinieneś wiedzieć. Po pierwsze najbardziej sensownym rozwiązaniem w przypadku budowania strony na podstawie frameworka jest wpisywanie własnych styli w oddzielnym pliku CSS (np. custom.css). W wypadku dużych portali to bardzo prosty sposób do tego aby obok rozwiązań frameworka stworzyć swój własny, rozbudowany arkusz styli, w którym to i tak będziemy zmuszeni wymyślić jakieś sensowne zasady konstrukcyjne i którym to bardzo często będziemy nadpisywać deklaracje z plików CSS frameworka. Po drugie największą zaletą frameworków jest to, iż pozwalają nam przyśpieszyć proces kodowania – w końcu zawierają w sobie tony kodu, którego nie musimy szukać w Google (tfu… tzn. pisać!). Jeśli tworzymy swój własny portal na podstawie frameworka frontendowego to niestety i tak będziemy musieli dopisać wiele linijek kodu i do jego napisania potrzebna będzie umiejętność prawidłowego konstruowania arkuszy stylów.
Dlatego uważam, iż framework nie gwarantuje nam uporządkowanego kodu – chyba że chcesz aby Twoja strona wyglądała jak demo site Foundation albo Bootstrapa.
BEM, OOCSS, SMACSS i inne skróty
Kiedy pierwszy raz stanąłem przed zadaniem napisania arkusza styli dla dużego portalu muszę przyznać, że nie byłem zadowolony z pierwszych efektów. Okazało się, że w kodzie CSS jest się ciężko zorientować, jest w nim mnóstwo powtórzeń, nie semantycznie nazwanych klas i ogólnie wiele innych pretekstów do refaktoryzacji kodu. Rzeczywiście. Na końcu tego projektu cały arkusz styli został przebudowany.
Problem polega na tym, że zapewnienie wewnętrznej spójności pliku CSS nie jest proste w przypadku dużych projektów. Przyczyn jest wiele, a sporą ich część można określić jako 'nie techniczne’. Często projekt graficzny otrzymujemy w ratach, pewne rzeczy zmieniają się na życzenie klienta, ktos zmienia zdanie itd. Niestety osobą pisząca stronę jako osoba będąca poniekąd na końcu całego większego procesu zostaje z problemem poradzenia sobie z tymi sytuacjami. Inną sprawą jest to o czym pisałem na poczatku tegoż akapitu – pisanie rozbudowanych arkuszy stylów po prostu nie jest proste (dokładnie tak – odpowiedź jest aż tak prosta!).
Dlatego swego czasu zainteresowałem się podejściami tytułowanymi róznymi skrótami np. BEM, OOCSS, SMACSS. Zainteresowało mnie też coś co również dorobiło się swojego skrótu – DRY. Przyznam szczerze, że żadne z tych podejść do pisania CSS nigdy nie zdobyło mojej wyłącznej i całkowitej sympatii, czy aprobaty. Jednak czytając kolejne zasoby Internetu odkrywałem co raz ciekawsze sposoby na rozwiązywanie męczących mnie problemów.
Tutaj moja rada jest prosta – szukaj własnych rozwiązań korzystając z doświadczeń innych. Wszystkie te metodologie powstały na bazie czyiś doświadczeń. Ludzie je opracowujący przelali na nie swoje doświadczenia z projektami i poukładali tak jak oni uważają za słuszne. W informacjach na temat tych metodyk znajdziesz wiele celnych uwag i wyśmienitych pomysłów na to jak pisać arkusze stylów. Jednak nie warto za bardzo przywiązywać się do jednej z nich. Szybko zauważysz, że żaden autor nie ma absolutnej racji od początku do końca.
Szalone selektory
Uszczegółowiając to co pisałem powyżej radziłbym od samego początku planować arkusz stylów w sposób modułowy. Co to oznacza? Przede wszystkim postarajmy sobie nakreślić ogólny schemat witryny i wytyczyć główne obszary tworzonej strony. Dopasujmy do każdego obszaru nadrzędną klasę i starajmy się stylować elementy wewnątrz tegoż obszaru w następujący (lub podobny) sposób:
1 2 3 4 5 6 7 8 9 | .Sidebar { width:30%; padding:10px; } .SidebarTopBox { height:300px; border-bottom:1px solid black; } |
Take podejście ma w sobie coś z BEM. Chodzi o zastąpienie selektorów przodków sposobem bardziej przejrzystym i łatwiejszym w czytaniu aby uniknąć sytuacji stworzenia arkuszu pełnego szalonych selektorów. Używanie takiego schematu nazw to swego rodzaju sztuczka, ale jest ona efektywna gdyż z jednej strony możemy tworzyć rozwiązania modułowo, z drugiej zaś możemy tworzyć rozwiązania podobne do wytycznych OCSS. Z trzeciej strony unikamy uciekania w szczegółowość po to by radzić sobie z narastającymi problemami związanymi z dziedziczeniem stylów i kaskadowością. W każdym razie nie powinniśmy pisać czegoś takiego (albo jeszcze gorszego):
1 2 3 | .Site #Sidebar > ul.Links li a.Active { //deklaracja } |
Zlintuj się
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. Chociażby pomaga by coś takiego:
1 2 3 4 5 6 7 8 9 10 | .Klasa { color:#fff; background:red; padding:10px; width:100px; margin-top:10px; border-bottom:1px solid black; height:500px; text-align:center; } |
Mogło wyglądać tak:
1 2 3 4 5 6 7 8 9 10 | .Klasa { width:100px; height:500px; padding:10px; margin-top:10px; background:red; border-bottom:1px solid black; text-align:center; color:#fff; } |
Dlatego zachęcam do używania tego narzędzia i przyswajania sobie dobrych praktyk, które ono propaguje.
ID jest be
Atrybut id i selektory na nim oparte to takie bomby atomowe kaskadowych arkuszy stylów. Generalnie nie powinno się ich używać, a ich rozprzestrzenianie powinno być zabronione (albo chociaż ograniczone). Krótko i na temat – nie stosuj, chyba że jest to na serio do czegoś niezbędne.
Rozdzielenie arkuszy
Na etapie deweloperskim bardzo dobrym pomysłem jest segmentacja kodu, czyli rozdzielenie naszego arkusza na 'mniejsze’ elementy. Możemy sobie to łatwo wyobrazić na zasadzie podziału na np.: typo.css, grid.css, theme.css itd. Operowanie na mniejszej ilości linijek kodu ma oczywiste zalety i sprzyja przejrzystości całości.
Trzeba jednak pamiętać o tym by przed 'deploy’em’ owy kod złączyć w jednym pliku i pewnie najlepiej skompresować. Poza tym juz na etapie podzielenia arkusza na mniejsz pliki powinniśmy przyjąć sobie w jakiej kolejności będziemy układać te pliki w całość.
Efektywne arkusze stylów
O optymalizacji arkuszy stylow wiele się pisało i nadal wiele się pisze. Jeśli chodzi o sprawy związane stricte z pisaniem arkusza stylów warto pamiętać o tym, że to co najbardziej negatywnie wpływa na szybkość renderowania się strony (bo dokładnie o tym mówimy) to to co znajduje się w deklaracjach. Same używane selektory nie są aż tak istotne jak by się mogło wydawać. Najbardziej problematyczne są właściwości i wartości, które wymagają od przeglądarki rekalkulacji, a im ich więcej w deklaracji i w arkuszu stylów tym oczywiście gorzej dla czasu renderowania strony.
Kolejnym kopem w szybkość działania arkusza stylów jest budowanie ogromnych arkuszy nieużywanych deklaracji. Kompresja i inne sztuczki to na prawdę tylko półśrodki. Czasami warto po prostu poodkurzać plik CSS i wyrzucić to co już nie jest potrzebne.
Możecie się spytać po co o tym pisać w tym artykule? Otóż skoro już rozmawiamy o tym jak pisać CSS to warto i ten graniczny temat poruszyć.
Zdjęcie pochodzi z: www.freedigitalphotos.net
Tagi: promowany
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/
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.
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.
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
>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.
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 ;)
>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.
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ę.
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.
>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ę ;)