7 złych praktyk CSS, których musisz unikać

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.

 

Spodobał Ci się artykuł? Dzięki naciśnięciu serduszka poniżej będę wiedział jakie treści tworzyć. Dzięki! :)

12 niesamowitych karuzel CSS/JS Kolekcje buttonów, których możesz użyć w kolejnym projekcie 14 stylów CSS dla cytatów
View Comments
  • Ja czasem korzystam z inline jak np. w Angularze chce do backgroundu diva wsadzić linka z JSa albo pomanipulować wysokością diva.

  • No to takie oczywiste (y) ale git

    • 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ń 😀

  • 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.

  • 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.

    • 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ą 🙂

    • 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 🙂

      • 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 ?