13 dobrych praktyk, które sprawią, że Twój kod CSS stanie się lepszy!

Ostatnio Bartłomiej Mąkina z bloga Devcorner.pl stworzył artykuł, w którym wymienia 7 złych praktyk podczas pisania kodu CSS. Zainspirowało mnie to do stworzenia swojego wpisu, w którym przedstawiam przeciwieństwo, czyli dobre praktyki 🙂

Dowiemy się dziś dlaczego w ogóle warto zwracać uwagę na poprawność naszego kodu CSS oraz poznamy dokładnie 15 sposobów na zwiększenie jego jakości.

Dlaczego warto stosować dobre praktyki w przypadku kodu CSS?

Korzystanie z dobrych praktyk ma szereg zalet. Przede wszystkim nasza witryna działa szybciej i wydajniej. Zawartość nie ma problemów z ustawianiem się na stronie, a przejrzysty oraz ułożony kod jest łatwiejszy do odczytania przez nas, jak i inne osoby, na przykład współpracowników.

Dobre praktyki:

1. Normalizacja stylów przeglądarki.

Zacznę od sposobu, o którym sam dowiedziałem się na późnym etapie nauki. Każda przeglądarka posiada własne, domyślne style, które potrafią przysporzyć sporej ilości problemów podczas tworzenia strony internetowej.

Właśnie to często jest powodem sytuacji, w której tworzymy witrynę i przykładowo na Chromie wygląda dobrze, po czym sprawdzamy ją na Firefoxie, gdzie jest zupełnie inna. Na szczęście możemy tego bardzo prosto uniknąć. Wystarczy dodać do naszych stylów kod z tej oto strony: Normalize.css.

Warto wspomnieć, że oprócz normalizacji istnieje coś takiego jak zupełny reset stylów przeglądarki. Aby go zastosować, wystarczy dodać kod z tej strony na początku naszego arkusza stylów.

2. Używanie box-sizing: border-box.

Domyślną wartością dla box-sizing _jest content-box_, ale niestety ta opcja sprawia wiele problemów. Postaram się wytłumaczyć dlaczego, na przykładzie kodu:

.div1
{
    box-sizing: content-box;
    width: 100px;
    height: 100px;
    padding: 10px;
    border: 5px;
}

W tym przypadku div ma 100px, ale osobno zostaje do niego dodany padding i border, które w praktyce sprawiają, że całość ma 130px.

.div2
{
    box-sizing: border-box;
    width: 100px;
    height: 100px;
    padding: 10px;
    border: 5px;
}

Tu już jest zupełnie inaczej. Całość ma 100px, a padding oraz border odejmują się od wymiarów diva, przez co ten ma w praktyce 70px szerokości i wysokości.

Warto zaznaczyć, że najczęściej box-sizing: border-box implementuje się w ten oto sposób:

html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

Jest to najlepsza praktyka, która rozwiązuje wszystkie problemy. 🙂

Zmiana tej wartości daje nam większą kontrolę nad układem strony i sprawia, że całość się nie “rozjeżdża”.

3. Łączenie stylów dla wielu elementów.

Możemy nadać takie same style dla więcej niż jednego fragmentu naszej strony. Dla przykładu chcąc ustawić kolor czcionki na ciemnogranatowy, dla nagłówków h1 do h3 nie użyjemy takiego kodu:

h1
{
    color: #10131a;
}
h2
{
    color: #10131a;
}
h3
{
    color: #10131a;
}

…a taki:

h1, h2, h3
{
    color: #10131a;
}

Nasz kod stanie się bardziej przyjazny dla ludzi, jak i przeglądarek.

4. Używanie zapisu szesnastkowego lub RGB.

Kolory dobrze jest pisać w jednej z tych dwóch postaci. Przykładowo nie używać takiego zapisu:

h1
{
    color: black;
}

…a taki:

h1
{
    color: #000000;
}

Dzięki temu nasz kod będzie trzymał się jednego standardu oraz stanie się przyjemniejszy w interpretacji.

5. Łączenie kodu w jedną linię.

Co rozumiem przez to zdanie? Gdy mamy element, któremu trzeba nadać różny margines z każdej ze stron nie używajmy takiego kodu:

div
{
    margin-top: 10px;
    margin-right: 5px;
    margin-bottom: 20px;
    margin-left: 15px;
}

…a taki:

div
{
    margin: 10px 5px 20px 15px;
}

Z kolei gdy ten margines jest taki sam od góry i dołu, a inny po bokach, to ponownie nie piszmy tego w ten sposób:

div
{
    margin-top: 10px;
    margin-right: 5px;
    margin-bottom: 10px;
    margin-left: 5px;
}

…a w ten:

div
{
    margin: 10px 5px;
}

Dzięki temu nasz kod będzie krótszy i szybciej ładowany przez przeglądarki.

6. Organizacja kodu.

Ważne jest aby nasz kod był ułożony w taki sposób, jak wygląda budowa strony. Przykładowo nasze style mogą być zorganizowane wg. takiej oto hierarchii:

/* Reset stylów przeglądarki */
/* Style ogólne */
/* Czcionki i ułożenie elementów na stronie */
/* Nagłówek */
/* Główna zawartość witryny */
/* Stopka */
/* Media Queries */

Dodatkowo cały kod powinien posiadać komentarze odgradzające poszczególne sekcje i elementy stron.

Wszystkie te dobre praktyki sprawią, że kod będzie bardziej przejrzysty i prostszy do odczytania przez nas, jak i przeglądarki internetowe.

7. Nieużywanie deklaracji !important.

Ta zła praktyka jest bardzo często poruszana, z racji tego, że jej działanie jest tragiczne w skutkach. Za jej pomocą zupełnie zaburza się hierarchię kodu CSS oraz znacznie utrudnia późniejszą edycję.

8. Używanie text-transform, zamiast caps locka.

Jeśli dane zdanie w całości ma być napisane z wielkich liter, to dobrze jest nie robić tego w ten oto sposób:

<p class="distinction">ZDANIE Z WIELKICH LITER</p>

…a w ten:

.distinction
{
    text-transform: uppercase;
}

9. Dodawanie animacji na końcu.

Wszelkie animacje widoczne na stronie, szczególnie biblioteki, takie jak np. Animate.css powinny być dodane na końcu po to, aby właściwa treść mogła pojawiać się przed nimi.

Dzięki temu witryna będzie ładować najpierw właściwą treść, a dopiero później wszelkie dodatki.

10. Niepowtarzanie tego samego kodu.

Jeśli na przykład posiadamy ciemne tło i białą czcionkę dla wielu elementów na stronie, to nie przypisujmy tego dla każdego elementu. Lepiej zróbmy to na przykład w ten sposób:

html
{
    background-color: #333333;
    color: #ffffff;
}

Oczywiście nie wszystkie style są dziedziczone (np. margines). W tym miejscu możecie znaleźć listę wszystkich elementów, które działają w ten sposób.

11. Posiadanie jednego pliku CSS.

Bardzo dobrze jest połączyć cały kod w jeden plik, po to aby ograniczyć ilość zapytań, które znacznie spowalniają ładowanie się strony (swoją drogą świetnie byłoby zrobić tak samo dla skryptów JavaScript 🙂).

12. Utrzymywanie kodu CSS poza plikiem HTML.

W sumie po to aby oddzielić treść strony od jej wyglądu, zostały stworzone kaskadowe arkusze stylów. 😉 Całość szczególnie dotyczy stylowania in-line, które jest bardzo dużym błędem i wygląda w ten sposób:

<h1 style="color: #10131a;"></h1>

13. Minifikacja kodu.

Zabieg ten polega na usuwaniu wszystkich znaków białych z naszego kodu. Często też rozwiązuje problem powtórzeń. W tym celu istnieje mnóstwo narzędzi, takich jak CSS Minifer oraz CSS Compressor.

Dzięki temu nasza strona waży mniej i ładuje się szybciej.

Podsumowanie.

W tym artykule wypisałem dobre praktyki, które warto stosować podczas pisania kodu CSS. Mam nadzieję, że niektóre okażą się dla Ciebie pomocne i pomogą w tworzeniu jak najlepszych stron internetowych. 🙂

Oczywiście jeśli masz jakieś pytania lub sugestie, to zapraszam Cię do komentowania, a jeśli ten artykuł okazał się dla Ciebie wartościowy, to będę bardzo wdzięczny, gdy udostępnisz go swoim znajomym lub czytelnikom. Powodzenia w tworzeniu jak najlepszych stron internetowych! 🙂

Programista zakochany w JavaScript'cie, twórca stron internetowych i jak widać od niedawna bloger 🙂
21 comments Add yours
  1. Nie spotkałem dotąd przeglądarki, która nie ogarnia krótkich kodów heksadecymalnych. Tak samo zastanawia mnie powód, dla którego odradza się korzystania z nazw kolorów – radzą sobie z nimi nawet starsze IE, co można sprawdzi na tabelce kolorów ze specyfikacji. Jedynym sensownym powodem, dla ktorego jestem w stanie zrozumieć nieużywanie nazw kolorów, jest standaryzacja – żeby wszystkie kolory zapisywać tym samym sposobem (bo nie wszystkie mają nazwy).

    Przy resetowaniu z kolei warto także wspomnieć o normalizacji.

    Nie mogę się z kolei zgodzić, że walidowanie kodu CSS jest dobrą praktyką. Nie przy pomocy oficjalnego walidatora, który zatrzymał się w roku 2010 i np. nie ogarnia składni calc.

    Natomiast punktu 9 w ogóle nie rozumiem. Jak przesunięcie definicji animacji na koniec arkusza stylów może zmienić czas ładowania strony?

    1. No i przy border-box margines NIE jest odejmowany od wielkości elementu – bo w nią nie wchodzi. Margines to margines.

      1. Hej! Dziękuję Ci bardzo za wszystkie rady Tomaszu!

        Wspomniałem o pisaniu kolorów w ten sposób właśnie z tego powodu, który wymieniłeś, czyli standaryzacji. Barw, które można zapisać szesnastkowo jest jednak znacznie więcej i później troszkę dziwnie czyta się kod, gdy jeden odcień zielonego jest zapisany jako “green”, a drugi jako ciąg cyfr 🙂 Co do kolorów w postaci trzycyfrowej, to pamiętam, że dowiedziałem się o tym na jednym z polskich webinarów i niepotrzebnie przyjąłem to jako prawdę, a tym bardziej niepotrzebnie o tym wspominałem w artykule.

        Co do normalizacji, to rzeczywiście przeoczyłem ten temat. Już poprawiam.

        Z kolei dziękuję bardzo za wyprowadzenie z błędu w przypadku walidatora. Wiedziałem, że nie jest on do końca aktualny, ale nie spodziewałem się, że aż do tego stopnia!

        Punkt 9 zupełnie źle sformułowałem, przez co trochę wprowadza w błąd. Chodziło mi o biblioteki animacji i to, aby ładować je po właściwych stylach CSS.

        Podobnie źle napisałem o border-box. Oczywiście chodziło mi o padding oraz border.

        Jeszcze raz bardzo Ci dziękuję oraz zabieram się do poprawiania wpisu! 🙂

    1. Dziękuję Ci Bartłomieju za te słowa! Bardzo miło je słyszeć! 🙂

      Również Tobie życzę samych sukcesów w prowadzeniu bloga! 🙂

    1. Dziękuję Ci bardzo za dobre słowa, naprawdę dużo dla mnie znaczą 🙂

      Również Tobie życzę wszystkiego co najlepsze podczas prowadzenia bloga! 😉

    1. Świetny wynik Dominiku! 🙂

      Dziękuję Ci bardzo za tak wiele miłych słów i również Cię pozdrawiam! 🙂

  2. box-sizing: border-box.

    Mistrz! Czemu nigdzie wcześniej nic o tym nie przeczytałem, mimo że przeglądałem wiele stron i tutoriali?

    1. Dziękuję Ci Kordianie! 🙂

      Nie mam pojęcia dlaczego ta właściwość jest podawana w tak niewielu miejscach. Sam na nią trafiłem zupełnie przypadkowo, podczas oglądania filmiku o media queries 😉

  3. Tekst fajny. I ja dodam 5 groszy:
    1. Nie tylko normalize jest ale i reset. Przy wielu projektach sprawdzi sie on lepiej. Teoria teorią, a w praktyce sa projekty gdzie ciagle zerowanie kolejnych list jest bardzo upierdliwe
    2. Dalbym box-sizing dla *, *:before, *:after {box-sizing:border-box}. Dzięki temu zapomnial bym o tej “nalecialosci standardow”
    4. W wielu przypadkach rgba czy hsla sa wygodniejsze czy wrecz konieczne w uzyciu (latwiej to ogarnac w glowie a i daja mozliwosci uzywania przezroczystych kolorow)
    5. Malo wyjasnione. Kiedy laczymy jednostki w jedna, kiedy w dwie a kiedy w cztery?
    6. Dodalbym tekst o tym czy uzywac stylowania przez id czy znaczniki. Czy to sa dobre praktyki? Moze to temat na inny art “jak pisac css i co to jest css specyfity”?
    8. To nie jest prawda. Wszystko zalezy od tresci. Mozna by spotkac slowa czy zdania napisane w oryginale duzymi literami. (czepiam sie!)
    10. To jest raczej “taka se” porada. Jasne – co do koloru jest to dobra rzecz. Ale ta rada nie zawsze zadziala. Nie wszystko jest dziedziczone –
    np nie bg (https://stackoverflow.com/questions/5612302/which-css-properties-are-inherited). Dla takich wspolnych styli albo lepiej uzywac jakiejs wspolnej klasy albo @mixin. Ale to znowu moze temat na osobny art?

    Tekst dobry. Pozdr.

    1. Dziękuję Ci bardzo za feedback! 🙂 Może odpowiadając, podobnie jak Ty odniosę się do konkretnych punktów.

      1. Jeszcze jakieś dwie godziny przed Twoim komentarzem w tym miejscu znajdowała się wzmianka o resecie, ale otrzymałem trochę informacji o tym, że nie jest to już uznawane za dobrą praktykę. Szczerze nigdy go nie potrzebowałem – zawsze wystarczała normalizacja, ale skoro mówisz, że istnieją sytuacje, gdy ta nie wystarcza, to dodam z powrotem informację o resecie stylów CSS. 🙂
      2. Jeśli chodzi o box-sizing, to rzeczywiście zawsze lepiej będzie dać od razu najlepszą opcję, a nie tę najprostrzą.
      4. Oczywiście, gdy chcemy chcemy mieć przezroczyste tło, to trzeba użyć RGBA, ale w tym miejscu bardziej chodziło mi o to aby nie używać zapisu słownego i starać się ich nie mieszać, a nie bezwzględnie tego nie robić. Już dodaję stosowną informację. 🙂
      5. Już dopisuję potrzebny akapit do artykułu.
      6. Chętnie o tym napiszę, tylko, że z tego co widzę, to w internecie jest różne podejście do tej sprawy. Jedni uważają, że nie powinno się stylować po znacznikach, a inni nie widzą w tym nic złego. Poczytam o tym więcej i całkiem możliwe, że stworzę osobny wpis, bo temat jest ciekawy. Dziękuję za pomysł na artykuł! 🙂
      8. Oczywiście są takie miejsca, ale jednak ogólnie przyjęte zostało, że teksty z wielkich liter nie powinny być umieszczanie w HTMLu, a odpowiednio ostylowane w CSSie.
      10. To jest bardzo ciekawa kwestia, którą świetnie rozwiązuje Twój link, muszę go dodać do artykułu 🙂

      Jeszcze raz Ci dziękuję, za tyle świetnych rad, 2 pomysły na wpisy i miłe słowa na końcu. Również Cię pozdrawiam! 🙂

  4. Dodatkowo przy zapisywaniu nazw kolorami, ktoś może mieć zmodyfikowane domyślne ustawienia i kolor czarny mieć ustawiony jako np niebieski 😉 Dlatego warto zapisywać konkretnych jednostek, np hex, rgb

  5. 13. Minifikacja kodu

    Wiem że to wypływa na prędkość wczytywania strony. Jednak czy to aby dobre rozwiązanie bo na przykład później chcemy edytować jakaś class-e i mamy po otwarciu pliku ścianę płaczu.
    “6. Organizacja kodu” wtedy ten punkt przechodzi do lamusa kosztem punktu 13 🙂

    1. Oczywiście. Dlatego minifikację dobrze jest wykonywać tylko po zakończeniu prac nad stroną, gdy wgrywamy ją na serwer. 🙂

      Jasne, że gdy zamierzamy tę witrynę jeszcze później edytować, to możemy zrobić kopię tego samego pliku przed minifikacją. Z kolei jeśli nie zamierzamy trzymać niepotrzebnych plików na dysku, to świetnym narzędziem jest CSS Beautifier, który to rozwiązuje nasz problem. 🙂

      Dziękuję Ci bardzo za ten świetny komentarz! 🙂

      1. Ale przecież minifikacja w dobie automatyzacji (Grunt, Gulp, npm scripts) i podziału na środowisko developerskie i produkcyjne nie stanowi żadnego problemu.

        1. Narzędzia, które wymieniłeś są świetne, ale jednak zwykle jest tak, że gdy ktoś uczy się tworzenia stron, to najpierw ciekawi go w jaki sposób zwiększyć szybkość ładowania się witryny, a dopiero później automatyzuje cały proces.

          Dla takiej osoby narzędzia, które podałem w poprzednim komentarzu mogą okazać się przydatne. 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *