Mistakes Słuchaj, nie musisz, być specjalista czy grafikiem, aby znać CSS. Jeżeli określasz się jako FullStack, to znaczy, że znasz także CSS. Pytanie jednak brzmi czy pomimo tego, że znasz CSS, to wiesz, jaki błędów warto unikać.

CSS nie jest intuicyjny. Ma pewne ukryte zasady, które odkryjesz, dopiero gdy zobaczysz, że coś nie działa. 

Praca z samym CSS może być mimo wszystko przyjemna, ale aby tak było na pewno trzeba unikać pewnych błędów.

Oto 11 z nich.  

1. Śledzenie DOM w CSS 🚫

Spójrz na ten HTML

<body>
    <div class="main-content">
      <div class="blog-row">
        <div class="blog-col">
          <section>
            <article>
              <span><a href="#">Ten link jest normalny</a></span>
              <p><span><a href="#" class="bold">Ten link jest pogrubiony</a></span></p>
            </article>
          </section>
          <section>
            <span><a href="#">Ten link jest normalny</a></span>
          </section>
        </div>
      </div>
    </div>
</body>

Jako programista nie chcesz zapewne, aby twój HTML był wierszykiem klas CSS. 

Jednakże pisanie styli, które są sztywno powiązanie, z daną strukturą HTML wydaje się jeszcze gorszym pomysłem.

body .main-content .blog-row 
.blog-col section article p span a {

    font-weight: bold;

}

Ten minimalizm klas CSS w pliku HTML jak widzisz, może być zdradliwe. Teraz masz bałagan w pliku CSS. Poza tym, jeżeli zmienię strukturę, tego pliku HTML to dany styl przestanie działać.

Styl CSS nie powinien być zależny od struktury pliku HTML

Mając natomiast klasę, reprezentująca daną właściwość daje Ci większą wygodę.

.bold {

   font-weight: bold;       
                 
}

W każdej chwili możesz tę klasę dodać/usunąć do elementu HTML.

Co więcej, ta technika także uchronić Cię przed !important. Najczęściej nadużywamy "!important" gdy mamy tak złożoną logikę działającą na strukturach HTML, że aż sami się w niej gubi i stwierdzamy, że musimy użyć !important tu i tam.

2. Używanie px jako jednostki 🚫

Za używanie samych pikseli nikt Ci głowy nie urwie. CSS jednak posiada parę RELATYWNYCH rozmiarów. Zamiast zgadywać, ile pikseli margin-top powinien mieć, gdy masz napis o wielkości 18px dla ekranu 1000px, a ile, gdy ten napis  napis ma 16px dla ekranu 350px.

Możesz zastosować relatywne rozmiary.

Zamiast więc pisać taki styl. 

p {
  font-size: 18px;
  line-height: 27px;
  margin-bottom: 10px;
}

Lepiej jest go napisać tak.

body {
  font-size: 18px;
}
p {
  font-size: 1rem;
  line-height: 1.5;
  margin-bottom: 0.5em;
}

Problem z pikselami polega na tym, że każdy użytkownik będzie miał innym rozmiar ekranu, jak i inny rozmiar viewport. 

Dla przypomnienia 1 rem odwołuje się do głównego rozmiaru, który został podany w najwyższym elemencie jak HTML,BODY. Czyli 1 rem to 18px.

1 em określa się do rozmiaru swojego rodzica. Może to być DIV, SPAN i tak dalej.

<div class="container">
    <div class="child_inside_container"></div>
</div>

.container {
    font-size: 20px;
}

.child_inside_container {
    width: 3em;
}

W tym przypadku "child_inside_container" będzie miał 60px.

Nie zapomnij także o % i o rozmiarach viewport, które fantastycznie się sprawdzają dla responsywnych tekstów.

3. Projektowanie najpierw na komputer czy na telefon ❓

Zanim zaczniemy pisać pierwsze style CSS, to warto ustalić dla kogo i dla jakich urządzeń piszemy stronę internetową. 

Jeżeli tworzysz stronę wewnątrz dla firmy i wiesz, że nikt jej nie uruchomi z telefonu, to masz bardzo ułatwione zadanie. Nie tworzysz layoutu dla małych ekraników.

To jest jednak wyjątek. W praktyce, nawet jeśli uznasz, że twoją stronę internetową 95% użytkowników przegląda na komputerze to boty SEO od Google będą określać użyteczność twojej strony na podstawie tego, jak ona wygląda na telefonie.

Jeżeli umieszczasz linki do swojej strony w mediach społecznościowych, to możesz być pewny, że ktoś kliknie link ze swojego telefonu niż komputera.

Jak więc dobrze zaprojektować stronę, gdy wiesz, że na pewno musi ona dobrze wyglądać na komórce.

W takim wypadku na pewno łatwiej będzie, jeśli najpierw stworzysz stronę z filozofią "mobile first".

Łatwiej jest stworzyć stronę internetową dla telefonów i później ją przygotować na komputer niz odwrotnie. Mając stronę internetową na komputer, od razu myślisz, ile rzeczy można wcisnąć i wyświetlić 

Co może być kuszące, gdy chcesz wyświetlić masę reklam.

Jednak później taką stronę trzeba wyświetlić na komórkę i zaczyna się masa dylematów i bawienia się w "media Queries", aby to wszystko wcisnąć gdzieś.

No chyba nie chcesz ukrywać rzeczy, tylko dlatego, że nie masz pomysłu gdzie to umieścić, gdy uzytkownik ma telefon.

4. Brak schematu nazewnictwa 🚫

Jak więc powinniśmy nazywać swoje CSS? Łatwo jest na pewno zrobić bałagan.

Patrząc na swojej style na tym blogu mam mieszane uczucia. Niektóre style są z 2015 roku niektóre z 2020. Jak widać, że miałem różne pomysły na nazewnictwo.

Pytanie, czy same nazwy mogą Ci powiedzieć, co do dany element robi.

.metroWindowsWords {

}

.mainpageIcon {

}

.programingIcon {

}

.speechIcon {

}

.plusicon {

}

.cloud {

}


.cloudimg {

}

.cloudcontent {

}

    .cloudcontent p {
    }

.myinfo {

}

    .myinfo .cloudimg {

    }


.mycourse {

}

    .mycourse .subcourse {

    }

    .mycourse .alllink {

    }

.myauthor {

}

    .myauthor .cloudimage {

    }

    .myauthor .subauthor {

    }

Ważne jest, aby trzymać się jakiego schematu. Niż mieszać kilka filozofii naraz.

Jak nazwiesz swój styl dla obrazów : ".img, .image, .blog-img, .img-blog, .blog-image, .blog-img"

Jak nazwiesz styl określający z centrowany tekst : .center, .centre, .centered, .text-center, .align-center

Nazwy klas CSS ciężko jest zrefaktoryzować. To nie jest takie proste jak z językiem C# czy Java. Nazwy styli CSS są nie tylko w pliku HTML, są one także w plikach JavaScript.

Nigdy nie wiesz, jak zmiana nazwy klasy CSS wpłynie na stronę, więc ludzie tego nie robią.

Ciekawym rozwiązaniem jest BEM, który określa, aby pisać tak style, aby było wyraźnie widać dla jakiego elementu, pod stanu, pod elementu jest dana logika.

.button {
    display: inline-block;
    border-radius: 3px;
    padding: 7px 12px;
    border: 1px solid #D5D5D5;
    background-image: linear-gradient(#EEE, #DDD);
    font: 700 13px/18px Helvetica, arial;
}

.button--state-success {
    color: #FFF;
    background: #569E3D linear-gradient(#79D858, #569E3D) repeat-x;
    border-color: #4A993E;
}

.button--state-danger {
    color: #900;
}

W przyszłości być może będziemy pisać style w JavaScript, to rozwiązanie to się nazywa CSS-in-JS.

Przynajmniej wtedy zmiana nazwy styli CSS będzie duża łatwiejsza.

5. Brak czcionek zastępczych 🚫

Pamiętaj, że nie każdy użytkownik może posiadać twoją czcionkę. Istnieje zawsze też ryzyko, że czcionka, którą pobierasz z jakiegoś źródła, nie będzie wspierana przez system operacyjny.

W perfekcyjnym świecie każda czcionka zawsze by działa. 

Oto przykład co zrobić, gdy chcesz użyć Helvetica, ale nie masz pewności czy ta czcionka będzie na komputerze.

.selector {
    font-family: Helvetica, Arial, sans-serif;
}

.selector {
    font-family: Helvetica;
}

Dlatego podaj po przecinku, alternatywne czcionki.

6. Używanie jednego pliku CSS 🚫

To może być subiektywne. Obecnie na przykład pracuje na jednym pliku CSS i szukam czego chce używając CTRL+F. 

Mimo wszystko jednak stwierdziłem, że podział na plik ułatwił mi by szukanie, gdybym miał wrócić do swojego projektu po latach.

Co ciekawe CSS oferuje operację "import", która pobierze wszystkie inne CSS za Ciebie. Tak, abyś nie musiał tej kolejności pilnować w wielu plikach HTML.

@import url("body.css");
@import url("cloud.css");
@import url("typography.css");
@import url("menu.css");
@import url("sidemenu.css");
@import url("metro.css");

Ostatecznie skorzystać z funkcji transpilatorów i kompilować wszystkie swoje style do jednego pliku.

7. Dokładna analiza rozwiązań. Co łamie przypływ dokumentu 🚫

To może wydawać się ciekawe. Powoli przechodzimy do błędów zależnych od zrozumienie : jak, co działa.

Jakie rozwiązanie jest najlepsze? Pomyśl. Na ile sposób można wyśrodkować element HTML horyzontalnie.

  • Użycie białych znaków spacji &nbsp; , aż element HTML będzie na środku
  • Ustawienie "width" i "margin-left" tak, aby element wydawał sie na środku
  • Użycie "text-align: center"
  • Użycie "margin: 0 auto"
  • Użycie kombinacji : position i left
  • Użycie : transform
  • Kombinacja "float" i "clearfix:both"

Pomyśl, jednak czego nie chcemy:

  • &nbsp; to szalone rozwiązanie
  • "width" z "margin-left. Skupia się na wartościach absolutnych. Dopóki wiesz, że one się zmienia, to może być okej. Zazwyczaj w 99% tak nie jest.
  • text-align: center . Działa, gdy display:inline. Akceptowalny
  • margin: 0 auto działa tylko dla "display:block". Akceptowalny
  • Użycie kombinacji : position i left. Jeśli działasz na elemencie Fixed lub Absolute to jest to akceptowalne rozwiązanie.
  • Użycie : transform . Może, ale brzmi zbyt szalenie

Najgorszy z tego jest float. On mam wpływ na elementy niżej. Co utrudni potem zrozumienie całościowe przepływu dokumentu i twojego pliku CSS.

On łamie przepływ dokumentu i nie mówiąc już, że mają do dyspozycji FlexBox i Grid nie powinieneś go stosować. 

Dlatego warto się zastanowić nad każdym rozwiązaniem dostępnym w CSS.

8. Style wzajemnie się wykluczają 🚫

Na pewno zdarzyło ci sie napisać jeden styl. Zapomnieć o nim i napisać kolejny, aby wkluczyć zasady zawarte w poprzednim stylu.

h2{
    font-size:2em;
    margin-bottom:0.5em;
    padding-bottom:0.5em;
    border-bottom:1px solid #ccc;
}
.no-border{
    padding-bottom:0;
    border-bottom:none;
}

Lepiej wtedy zrobić refactoring i rozbić elementy w odpowiedni sposób.

h2{
    font-size:2em;
    margin-bottom:0.5em;
}
.headline{
    padding-bottom:0.5em;
    border-bottom:1px solid #ccc;
}

Warto o tym pamiętać, zwłaszcza gdy wracasz do starego projektu i tworzenie styli, które wzajemnie sie nadpisują się, staje się normą.

10. Powtarzanie się styli 🚫

Jak w każdym języku nie chcemy się powtarzać. W CSS, gdy nie masz ogólnie pomysłu na początku jak strona ma wyglądać : powtarzanie jest prawie nieuniknione.

.some-title { font-weight: bold; }
.some-other-title { font-weight: bold; color: red }

h2 {
   font-weight: bold;
   color: red
}

h3 {
   font-weight: bold;
   color: red
}

Ten kod możesz skrócić:

.some-title, .some-other-title { font-weight: bold; }
.some-other-title { color: red; }

Zakładając też, że element HTML h2 i h3 będą mieć te klasy.

<h2 class="some-other-title ">Hej</h3>
<h3 class="some-other-title ">Hej</h3>

To jest jeden z powodów, dla których w SASS można potraktować style jak obiekt klas, które mogą dziedziczyć po sobie.

.some-title { font-weight: bold; }
.some-other-title { @extend .some-title; color: red; }

11. Używanie id, używanie atrybutów 🚫

Który z styli wygląda dobrze.

#my-link { color: red; }
.my-link { color: green; }
a { color: blue; }

Czy korzystanie z atrybutów będzie czytelniejsze?

[data-columns="3"] .col { width: calc(100% / 3); }
[data-columns="2"] .col { width: calc(100% / 2); }

Używanie ID tworzy wiele problemów. Po pierwsze strona HTML może mieć tylko jedno obiekt o takim ID. Często będziesz chciał użyć ponownie stylu i wtedy to ID zmieni się w klasę.

Dlaczego więc w ogóle z niego skorzystałeś?

Atrybuty nie są czytelne moim zdaniem i nie powinny mieć miejsca w CSS.

Podsumowanie

Słuchaj żaden plik CSS, nie jest idealny. Na tym polega ironia, że nawet gdy już wszystko działa to zapewne masz coś w swoim pliku co może Ciebie kopnąć później .

Jak każdy stary kod legacy.

Pamiętaj jednak, że im więcej wiesz czego unikać, tym większa szansa, że wygrasz tę walkę pomiędzy jakością  a potrzebą stworzenia strony internetowej byle szybciej.