Struktura plików CSS i skalowanie arkusza

Cele lekcji

Po ukończeniu tej lekcji będziesz umieć:

• rozpoznać moment, w którym jeden plik CSS zaczyna szkodzić utrzymaniu,
• podzielić style na warstwy: settings, reset, base, layout, components i utilities,
• zaplanować kolejność importów zgodną z kaskadą,
• wyznaczyć granice odpowiedzialności komponentów,
• używać utilities bez chaosu i duplikacji,
• skalować arkusz bez podbijania specyficzności i przypadkowych wyjątków.

Kontekst praktyczny

Na początku jeden plik style.css jest wygodny. Po kilkudziesięciu komponentach zaczyna być trudno znaleźć, gdzie zmienić przycisk, gdzie kończy się layout, a gdzie zaczyna jednorazowa poprawka. Struktura plików ma skrócić czas decyzji: nowy styl powinien mieć oczywiste miejsce.

Problem jednego pliku

Jeden plik może działać długo, ale bez sekcji i konwencji szybko zamienia się w historię przypadkowych dopisków. Najgroźniejsze są reguły, które wyglądają lokalnie, ale wpływają na cały projekt.

Kopiuj/* style.css */
.card h3 {
  margin-bottom: .5rem;
}

.dashboard .card h3 {
  margin-bottom: 0;
}

.settings-page .dashboard .card h3 {
  margin-bottom: 1rem;
}

To nie jest problem samego pliku, tylko braku granic. Reguły zaczynają poprawiać poprzednie reguły zamiast opisywać jasne odpowiedzialności.

Warstwy i foldery

Praktyczny podział powinien odpowiadać temu, jak działa CSS. Najpierw decyzje systemowe, potem reset i baza, później layouty, komponenty i utilities.

Kopiujstyles/
  settings/
    tokens.css
  reset/
    reset.css
  base/
    document.css
    typography.css
  layout/
    containers.css
    grids.css
  components/
    button.css
    card.css
  utilities/
    spacing.css

Nie każdy projekt potrzebuje dokładnie takiego drzewa. Ważne, aby podział pomagał decydować, gdzie dodać nowy styl i gdzie szukać istniejącego.

Kolejność importów

Kolejność plików jest częścią architektury. Importy powinny odzwierciedlać warstwy i kolejność nadpisywania, a nie przypadkową kolejność powstawania plików.

Kopiuj@layer settings, reset, base, layout, components, utilities;

@import url("./settings/tokens.css") layer(settings);
@import url("./reset/reset.css") layer(reset);
@import url("./base/document.css") layer(base);
@import url("./layout/containers.css") layer(layout);
@import url("./components/button.css") layer(components);
@import url("./utilities/spacing.css") layer(utilities);

Jeżeli projekt nie używa build toola, można nadal utrzymywać jeden plik końcowy, ale z czytelnymi sekcjami i komentarzami granicznymi.

Granice komponentów

Komponent powinien opisywać własną strukturę i warianty, ale nie powinien naprawiać layoutu strony. Layout decyduje, gdzie komponent stoi. Komponent decyduje, jak wygląda sam w sobie.

Kopiuj/* components/card.css */
.card {
  display: grid;
  gap: 1rem;
  padding: 1rem;
  border: 1px solid var(--color-border);
}

.card--featured {
  border-color: var(--color-action);
}

Jeżeli klasa komponentu zaczyna zawierać szerokość całej strony, offset sticky albo reguły siatki rodzica, to prawdopodobnie miesza się z layoutem.

Utilities

Utility to mała, przewidywalna klasa do konkretnego zadania. Może być bardzo przydatna, jeśli ma ograniczony zakres i jest w późniejszej warstwie niż komponenty.

Kopiuj@layer utilities {
  .u-stack-sm {
    display: grid;
    gap: .5rem;
  }

  .u-text-muted {
    color: var(--color-text-muted);
  }
}

Utilities nie powinny zastępować komponentów. Jeżeli budujesz cały przycisk z dziesięciu utility, początkującemu użytkownikowi trudniej zrozumieć intencję UI.

Skalowanie arkusza

Skalowanie CSS polega na kontrolowaniu kosztu kolejnej zmiany. Nowy komponent powinien wymagać dodania lokalnego pliku albo sekcji, a nie przeszukiwania całego arkusza i dopisywania wyjątków na końcu.

Kopiuj/* Dobra zasada decyzyjna */
settings  -> tokeny i decyzje systemowe
reset     -> wyrównanie startu przeglądarek
base      -> domyślne elementy HTML
layout    -> kontenery, gridy, regiony strony
components -> przyciski, karty, formularze
utilities -> małe świadome wyjątki

Jeżeli nie potrafisz przypisać reguły do żadnej kategorii, to często znaczy, że reguła robi za dużo albo opisuje jednorazowy hack.

Demo struktury CSS

Demo pokazuje różnicę między arkuszem, który rośnie przez dopisywanie poprawek, a arkuszem z jawnymi warstwami i odpowiedzialnościami.

Najczęstsze błędy początkujących

• Tworzenie wielu folderów bez realnej konwencji odpowiedzialności.
• Mieszanie resetu, layoutu i komponentów w jednej sekcji arkusza.
• Dodawanie wyjątków na końcu pliku zamiast poprawienia źródłowej reguły.
• Budowanie komponentów przez selektory zależne od konkretnej strony.
• Używanie utilities jako zamiennika dla czytelnych komponentów.
• Brak jednego miejsca dla tokenów, zmiennych i decyzji systemowych.

Mini zadanie

Zaprojektuj strukturę CSS dla małej strony z hero, kartami, formularzem i stopką.

• Rozpisz foldery lub sekcje: settings, reset, base, layout, components, utilities.
• Przypisz tokeny kolorów i odstępów do settings.
• Umieść reguły body, linków i obrazów w base.
• Przenieś kontenery i siatki do layout.
• Wydziel .button, .card i pole formularza do components.
• Dodaj maksymalnie trzy utilities i opisz, kiedy wolno ich używać.

Checklista

• Potrafię zaproponować strukturę plików CSS dla małego projektu.
• Rozumiem różnicę między warstwą base, layout i components.
• Wiem, dlaczego kolejność importów wpływa na kaskadę.
• Potrafię rozpoznać komponent, który robi za dużo.
• Używam utilities świadomie i w ograniczonym zakresie.
• Nie dopisuję wyjątków na końcu arkusza bez sprawdzenia źródła problemu.

Podsumowanie lekcji

Struktura plików CSS jest narzędziem do zarządzania decyzjami. Dobre foldery, warstwy i sekcje pomagają utrzymać niską specyficzność, ograniczyć duplikację i szybko znaleźć właściwe miejsce dla kolejnej reguły.

Kolejny krok roadmapy to pseudoklasy i pseudoelementy w praktyce.