Pisanie dobrego CSS

Opublikowany: 2016-10-17

Zawsze staram się uczyć nowych rzeczy. Jednak staram się również nauczyć sposobów na poprawę sposobu, w jaki już robię rzeczy. Zarówno na moim pełnoetatowym koncercie, jak i przy projektach po stronie klienta, zawsze chciałem ulepszyć mój CSS. Zawsze czułem, że jestem całkiem dobry, jeśli chodzi o CSS, ale zawsze uważałem, że czytanie jest brudne i często trudne w utrzymaniu.

To, co próbowałem zrobić, to dowiedzieć się, co sprawia, że ​​CSS jest dobry, czytelny i łatwy w utrzymaniu. Myślę, że wymyśliłem (i znalazłem) sposoby, aby to wszystko było możliwe.

Problemy

Jest kilka rzeczy, które przeszkadzają mi w CSS. Najczęstsze przykrości, jakie mam to:

  • powtarzanie wspólnego kodu
  • prefiksy przeglądarki
  • brak komentarzy
  • ponad wykwalifikowanych selektorów
  • kiepskie nazwiska klas

Jeśli chodzi o moje projekty osobiste, biorę pełną odpowiedzialność za swój kod. Rzadko komentuję mój CSS i często traktuję to jako refleksję. To po prostu źle.

Przez długi czas myślałem, że moje nazwy klas są „semantyczne” i to tylko ja robię różne rzeczy, więc nie ma potrzeby wyjaśniania kodu, ani małych „hacków” ani nic.

Powrót do kodu w długoletnim projekcie szybko dowodzi, że ta teoria jest bardzo błędna.

Jeśli chodzi o kod w pracy, nie mogę wziąć na siebie całej winy. W rzeczywistości częścią problemu jest liczba osób, które się tam znalazły. Obecnie nasz zespół liczy siedmiu z nas, którzy w pewnym momencie napisali CSS dla naszych witryn, a kolejne 6-8 pojawiło się i przejrzało lat. Każdy członek zespołu ma różny poziom wiedzy i umiejętności w zakresie CSS.

Ponadto, jak to często bywa w przypadku długotrwałych projektów, część kodu jest stara . Wiele z nich jest sprzed CSS3 lub sprzed tego, co było fajne 5 lat temu. W obu przypadkach często istniały różne sposoby robienia rzeczy w czasie, gdy został napisany, a w niektórych przypadkach naturalny brak wiedzy.

Dowiedziałem się również, że niektórzy programiści upierają się, że ich kod jest „samo-dokumentujący”. Jeśli nie znasz tego terminu, oznacza to, że „mój kod nie ma komentarzy”.

Rozwiązania

Chociaż nic nie jest doskonałe, wierzę, że są rzeczy, które możemy zrobić, aby ulepszyć nasz kod. Jakiś czas temu odkryłem CSS Guidelines autorstwa Harry'ego Robertsa. Jest to zgodne z obietnicą „Porad i wytycznych wysokiego poziomu dotyczących pisania rozsądnego, łatwego w zarządzaniu i skalowalnego CSS”.

Uwagi

Podczas gdy CSS Guidelines zawiera szczegółowe informacje na temat stylów komentarzy, ja osobiście staram się umieścić coś , co powie mi w przyszłości, o czym myślę. Każdy komponent zaczynam od komentarza reprezentującego tytuł, który zawiera szczegółowe informacje na temat przeznaczenia komponentu.

Używając preprocesora, stylizuję określone komentarze tak, aby były dołączone do CSS lub pominięte przez preprocesor. Nadal pracuję nad tą częścią i próbuję wyrobić w sobie nawyk umieszczania czegoś , czegokolwiek .

Orientacja obiektowa

Orientacja obiektowa to paradygmat programowania, który dzieli duże rzeczy na małe. Z Wikipedii:

Programowanie obiektowe (OOP) to paradygmat programowania, który reprezentuje koncepcję „obiektów” […], które zwykle są instancjami klas, [i] są używane do interakcji między sobą w celu projektowania aplikacji i programów komputerowych.

Jeśli chodzi o CSS, nazywamy to CSS zorientowanym obiektowo lub OOCSS . Podstawowa koncepcja odrywa strukturę pierwiastka od skóry pierwiastka. Oznacza to, że możemy łatwo ponownie wykorzystać powtarzające się wzorce projektowe, bez konieczności ponownego jednoczesnego wykorzystywania konkretnych szczegółów implementacji. OOCSS skupia się głównie na ponownym wykorzystaniu kodu, co czyni nas szybszymi i może zmniejszyć rozmiar naszego kodu.

Myślę o aspektach strukturalnych, takich jak szkielety; wspólne ramki, które dają konstrukcje znane jako object . Obiekty te to proste wzorce projektowe, wolne od jakichkolwiek kosmetyków. Abstrahujemy strukturę ze zbioru komponentów, aby uzyskać ogólny obiekt.

Następnie opcjonalnie dodajemy warstwę „skóry” do naszej struktury, aby nadać abstrakcjom określony wygląd i styl. Na przykład (zaczerpnięte z wytycznych CSS):

 /**
 * Prosty obiekt przycisku bez projektowania. Rozszerz ten obiekt o skórkę `.btn--*`
 * klasa.
 */
.btn {
    wyświetlacz: inline-block;
    wypełnienie: 1em 2em;
    wyrównanie w pionie: środek;
}

/**
 * Pozytywna skóra przycisków. Rozszerza `.btn`.
 */
.btn--dodatni {
    kolor tła: zielony;
    kolor biały;
}

/**
 * Negatywna skóra przycisków. Rozszerza `.btn`.
 */
.btn--ujemny {
    kolor tła: czerwony;
    kolor biały;
}

Tutaj widzimy, jak klasa .btn po prostu zapewnia strukturę elementowi, ale nie ma nic dotyczącego kosmetyków. Możemy rozszerzyć .btn o drugą klasę, taką jak .btn--positve , aby nadać temu elementowi bardziej specyficzną stylizację:

 <button class="btn btn--positive">OK</button>

Zdecydowanie wolę używać wielu klas w moim HTML, niż używać czegoś takiego jak @extend w preprocesorze. Daje mi to większą widoczność w moim kodzie HTML, co pozwala mi szybko zobaczyć, jakie klasy są stosowane do mojego elementu. Oznacza to również, że moje klasy nie są ściśle powiązane z innymi stylami w moim CSS. W pewnym sensie pomaga OOCSS w przestrzeganiu koncepcji enkapsulacji .

BEM

BEM ( Block, Element, Modifier ), to metodologia front-end opracowana w Yandex. BEM to właściwie bardzo kompletna metodologia i szczerze mówiąc, nie zagłębiałem się we wszystkie szczegóły, ale to, co mnie interesuje, to po prostu konwencja nazewnictwa.

Używam konwencji nazewnictwa typu BEM. Koncepcja jest taka sama, ale dokładna składnia może się nieznacznie różnić.

BEM dzieli zajęcia na trzy grupy:

  1. Blok: korzeń lub podstawa komponentu
  2. Element: komponent wewnątrz Bloku
  3. Modyfikator: odmiana lub rozszerzenie Bloku

Bardzo podstawowa analogia ( nie przykład):

 .pies {}
.psi_ogon {}
.pies--mały {}

Elementy są rozdzielane dwoma znakami podkreślenia (__), a modyfikatory są rozdzielane dwoma myślnikami (–).

W powyższej analogii widzimy, że .dog jest blokiem, korzeniem elementu. Wtedy .dog__tail jest Elementem, jest to mniejsza część Bloku .dog . Wreszcie, .dog--small to Modyfikator, specyficzna odmiana bloku .dog . Do elementów można również zastosować modyfikatory. na przykład, moglibyśmy mieć .dog__tail--short do ponownie, określić odmianę elementu dog__tail .

W niektórych przypadkach mogę potrzebować wielu słów dla bloków, elementów lub modyfikatorów. W każdym razie są one oddzielone pojedynczym łącznikiem (-), a klasy są zawsze pisane małymi literami .

Preprocesory

Spędzałem czas pracując nad preprocesorami CSS w swoim przepływie pracy i jak dotąd jest to niezwykle cenne. Preprocesory CSS pobierają kod napisany we wstępnie przetworzonym języku i konwertują go na stary dobry CSS. Nie są CSS, co oznacza, że ​​nie obowiązują te same zasady i ograniczenia CSS. Chociaż CSS jest świetny, nie zawsze pozwala nam łatwo robić to, co chcielibyśmy robić.

Na przykład jedną z rzeczy, która byłaby naprawdę fajna w CSS, są zmienne . Może chcesz, żeby lewy margines jednego elementu był taki sam jak szerokość drugiego i nagle ktoś uzna, że ​​te liczby muszą się zmienić. Ponieważ mają ten sam numer, a Twój układ może na nim polegać, musisz zmienić go w więcej niż jednym miejscu. Ale dzięki zmiennej można to zmienić w jednym miejscu i odzwierciedlić to w całym układzie. Oczywiście preprocesory to znacznie więcej niż tylko zmienne, ale to dopiero początek!

Oczywiście nie musisz używać preprocesora, ale myślę, że większość ludzi, którzy to zrobią, nie wróci. Wiem, że nie. Wzrost elastyczności i zwiększona czytelność to coś, z czego po prostu nie mogę zrezygnować. Po prostu możliwość korzystania ze zmiennych i domieszek wystarczy, abym się wciągnął.

Dostępnych jest kilka preprocesorów, ale jedyne dwa, na które naprawdę się przyjrzałem i które w ogóle używałem, to LESS i SASS . Proszę spojrzeć i rozważyć dodanie jednego z nich do swojego przepływu pracy, nie będziesz się cofać.

Podsumowując

Chodzi mi o to, że CSS może być lepszy. Wszystko może być lepsze. Ktoś niedawno powiedział mi w komentarzu pod postem na Reddicie, że „CSS nie ma semantyki”. Z całego serca się nie zgadzam. CSS 100%, bez wątpienia może być semantyczny.

Używanie OOCSS i BEM w rzeczywistości nadaje CSS bardzo semantyczne znaczenie. Nie oznacza to, że od samego początku jest to łatwe , ale warto je zbadać. Połącz to z preprocesorami CSS, a uzyskasz możliwość bardzo czytelnego, łatwego w utrzymaniu i skalowalnego CSS .

Chciałbym również zauważyć, że to nie tylko sprawia, że ​​Twój CSS (wstępnie przetworzony lub nie) jest bardziej czytelny, ale także sprawia, że ​​Twój HTML jest bardziej czytelny dzięki zastosowaniu semantycznych nazw klas do elementów.

TL; DR

Ok, może to było dużo – podsumowując, napisz lepszy CSS w ten sposób:

CSS zorientowany obiektowo :

  • każda klasa robi jedną rzecz — robi to dobrze, robi to dobrze

Nazwy klas stylu bloku, elementu, modyfikatora (BEM) :

  • Blok: .grid
  • Element: .grid__item (2 podkreślenia)
  • Modyfikator: .grid--wide (2 myślniki)

Preprocesory są niesamowite :

  • sprawdź je: MNIEJ – SASS
  • lub znajdź inne: 8 preprocesorów CSS, aby przyspieszyć czas tworzenia