W tym artykule poznasz 7 złych praktyk, których musisz unikać podczas pisania stylów CSS. Obok złych praktyk umieszczone są również ich przeciwieństwa – dobre praktyki. Dzięki temu możesz natychmiast poprawić jakość Twojego kodu.

Nadużywanie deklaracji !important

Deklaracja !important pozwala na nadpisanie wcześniejszych reguł dodanych do selektora (bez względu na specyficzność). !important jest często nadużywany z powodu lenistwa – łatwiej dodać tę regułę niż tworzyć bardziej/mniej specyficzny selektor.  Niestety powoduje to problemy w późniejszych pracach nad stylami i kod staje się znacznie trudniejszy w utrzymaniu.

Opisywanie stylów w nazwach selektorów

Nazwa selektorów nie powinna określać jego stylów. Spójrz na poniższy przykład. Pierwszy selektor .szare-tlo będzie poprawny tak długo, jak tło będzie szare. Problem w tym, że style często się zmieniają.

.szare-tlo { background-color: grey; } /* Źle */

.glowne-tlo { background-color: grey; } /* Dobrze */

Klient może zdecydować, że tło powinno mieć jednak inny kolor. Będziesz musiał zmieniać wtedy nazwę selektora, który już przecież odwołuje się do kilkunastu elementów na stronie. Drugą opcją będzie zmiana samego koloru:

.szare-tlo { background-color: red; } /* Bardzo źle */

.glowne-tlo { background-color: red; } /* Dobrze */

Jak widzisz selektor nieopisujący stylów (.glowne-tlo) będzie zawsze poprawny.

Powiązanie selektorów ze strukturą HTML

Kolejnym często popełnianym błędem jest wiązanie selektorów ze strukturą HTML

.footer > nav > li > button {  } /* Źle */

.footer-button {  } /* Dobrze */

Problem z pierwszym zapisem pojawi się podczas zmiany struktury HTML. Możemy zdecydować, że element nav powinien zostać umieszczony w dodatkowym divie. Cała reguła przestanie wtedy działać.

Drugi zapis będzie zawsze poprawny, bez względu na strukturę HTML.

Pisanie długich selektorów

Używanie zbyt długich selektorów powoduje problemy ze specyficznością. Efekt jest podobny do !important – kod staje się trudniejszy w utrzymaniu i modyfikacji.

#about .team .members div .person {  } /* Źle */

.person {  } /* Dobrze */

Zawsze bierz pod uwagę, że prawdopodobnie ktoś za kilka tygodni/miesięcy/lat będzie pracował nad Twoim kodem. Nie dokładaj innym/sobie niepotrzebnej pracy 🙂

Ignorowanie kolejności elementów HTML

Ignorowanie kolejności elementów HTML podczas pisania stylów CSS wprowadza niepotrzebne zamieszanie i nieporządek.

/* Źle */

.footer {  }
.header {  }

/* Dobrze */

.header {  }
.footer {  }

Pisz style CSS według kolejności elementów HTML.

Ignorowanie specyficzności w kolejności selektorów

Selektory powinny być ułożone w kolejności od najmniej specyficznego.

Źle:

.klasa:first-child {  }
.klasa {  }
.klasa:last-child {  }

Dobrze:

.klasa  {  }
.klasa:first-child {  }
.klasa:last-child {  }

Możesz zauważyć, że dobra praktyka jest jednocześnie złą (ignorowanie kolejności elementów HTML). To jest wyjątek, ponieważ działamy tutaj w obrębie jednego elementu.

Używanie stylów inline

Jest to jedna z najgorszych praktyk, mimo to nadal jest szeroko stosowana. Zaprzecza głównemu przeznaczeniu CSS, którym jest rozgraniczenie warstwy prezentacji od struktury. Style inline są również najbardziej specyficzne, więc jedynym sposobem na ich nadpisanie jest użycie !important.

<p style="font-size: 18px; color: red;">Korzystanie ze stylów inline to zła praktyka.</p>

Istnieje jednak jeden wyjątek – emaile HTML. Tutaj jesteśmy zmuszeni do ich użycia. Możemy jednak tego uniknąć używając frameworków takich jak MJML.

 

  • Mossar

    Ja czasem korzystam z inline jak np. w Angularze chce do backgroundu diva wsadzić linka z JSa albo pomanipulować wysokością diva.

  • OnceBuilder CMS

    No to takie oczywiste (y) ale git

    • bethart

      Oczywiste czy nie, zawsze warto przypomnieć, w końcu każdemu może się pojawić w głowie myśl o zdradzie (dobrych praktyk) i wtedy włącza się takie 7 przykazań 😀

  • Kornelia Kobiela

    Słowem: „Zawsze pisz swój kod tak, jakby miał go przeczytać psychopata-kanibal, który wie, gdzie mieszkasz”. Ta myśl powinna być wykładana na pierwszym roku studiów.

    • bethart

      A to dobre, ominęło mnie to 🙂 Na szczęście psychopata-kanibal raczej nie wziąłbym mnie na celownik 🙂

    • Kamil Rogala

      genialne! 🙂

  • Nux

    Z tym utrzymywaniem kolejności reguł według kolejności w strukturze HTML bym się nie zgodził. Problem na dłuższą metę jest podobny jak z selektorem szare-tło. Po jakimś czasie widżet może zostać przeniesiony np. z paska bocznego do stopki.

    Zresztą lepiej korzystać z Less i trzymać kod każdego widżeta w osobnym pliku, który jest importowany do głównego.

    • Bartłomiej Mąkina

      Takie „ruchome” elementy wyłączyłbym z tej reguły. Odnosiłem się tutaj do standardowych modułów na stronie.

      Rozdzielenie komponentów w LESS/SASS jest oczywiście dobrą praktyką 🙂

    • bethart

      Racja. Nie kwestionując przydatności Less/Sass warto pamiętać, że kod widżetów można (powinno się) także w czystym css’ie trzymać w osobnych plikach 🙂

      • Mike_P77

        No właśnie, ostatnio doszedłem do wniosku, że przy RWD fajnie byłoby trzymać reguły CSS dla kazdej obsługiwanej rozdzielczości w osobnym pliku, bo otwieram sobie ich kilka na duzym monitorze i zamiast scrollować po tasiemcu to tylko przełączam się między zakładkami. Jestem troche jednak do tyłu z obecnymi technologiami i nie wiem jak sobie to usprawnić. Chodzi mi o to, żeby jakimś narzędziem w magiczny sposób później łączyć te wszystkie pliki CSS w jeden plik. Podpowiecie czemu powinienem się bliżej przyjrzeć ? Gdzieś czytałem, że Gulp takie rzeczy robi, dobry wybór ?