close
CSS

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

css

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

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:

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

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.

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.

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.

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.

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.

 

Tags : praktyki CSS
  • Mossar

    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

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

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

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

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

        • Możesz użyć:

          1. LESS – https://devcorner.pl/kurs-less-blyskawiczne-tworzenie-stylow-css/ (zobacz pod nagłówkiem “Importowanie”).

          2. SASS – https://devcorner.pl/kurs-sass-dla-poczatkujacych-1-zagniezdzanie-zmienne-i-domieszki/

          SASS ma ogólnie większe możliwości, więc wybierałbym go z tych dwóch opcji 🙂

          • Mike_P77

            Dzięki, LESSa uzyłem kiedys w projekcie i jakoś o nim zapomniałem, bo wydawało mi się, że po pierwsze generuje niepotrzebnie zbyt długie łańcuchy reguł i po kompilacji konkretne atrybuty sa jeden pod drugim a mnie wygodnie pracuje sie jak są w jednej linii. LiveReload z tego co pamiętam nie umozliwiał zmiany ustawień w tym zakresie. Ale dzieki za podpowiedź, bo faktycznie importowanie załatwiałoby sprawę. Sprawdzę sobie jeszcze w wolnej chwili tego Koala, o którym piszesz. Dzieki 😉