Zmiana motywu kolorystycznego w materialize.css

Wstęp

Podmienie domyślnej kolorystyki biblioteki materialize.css nie jest tak oczywiste, jak mogłoby się wydawać. Dokumentacja nie wyraża dokładnie, jak taki proces powinno się przeprowadzić, a stackoverflow świeci pustkami w tym temacie (poza odniesieniami do starszej wersji tejże biblioteki). Jak to w takim razie zrobić?

Podmiana z użyciem SCSS

Najprościej i najefektywniej można to zrobić, instalując materialize-css i kompiler sassa przez npma. Dzięki temu, możemy zaimportować materialize do naszego głównego pliku scss i od razu podmienić wartości zmiennych:


$primary-color: #EE6E73; // "materialize-red", "lighten-2"
$primary-color-light: lighten($primary-color, 15%);
$primary-color-dark: darken($primary-color, 15%);

$secondary-color: #26A69A; // "teal", "lighten-1"
$success-color: #4CAF50; // "green", "base"
$error-color: #F44336; // "red", "base"
$link-color: #039BE5; // "light-blue", "darken-1"

@import '~materialize-css/sass/materialize.scss';

// Wszystkie zmienne mają przypisane defaultowe kolory 
// w komentarzach podałem domyślne wartości definiowane 
// w pliku _variables.scss biblioteki

Pierwsze 3 zmienne, tj. $primary-color, $primary-color-light i $primary-color-dark tworzą podstawę kolorystyki. Są one odpowiedzialne za kolor głównych modułów i elementów layoutu, np. nawigacji czy stopki. Jeśli chcemy podmienić główny kolor, robimy to poprzez zmianę wartości zmiennej $primary-color. Na jej podstawie zmienne $primary-color-light i $primary-color-dark otrzymują odpowiednio rozjaśniony i przyciemniony wariant koloru głównego.

Następnie mamy zmienne, które pozwalają na ustalenie wartości pozostałych kolorów, tj. koloru drugiego ($secondary-color), koloru sukcesu ($success-color), koloru błędu ($error-color) i koloru linków ($link-color). Po zdefiniowaniu wszystkich wartości zmiennych, możemy zaimporotwać materialize-css poprzez odwoładnie się do node-modules z użyciem znaku ~. Gdy zapiszemy plik, zobaczymy, że kolory aplikacji uległy zmianie.

Jest to o tyle wygodne rozwiązanie, że pozwala na podmianę wszystkich kolorów używanych przez bibliotekę – od elementów layoutu, do podkreśleń i etykiet pól formularzy, które są szczególnie trudne do okiełznania kolorystycznie gdy używamy skompilowanego pliku biblioteki materialize.css. W takim wypadku, osiągnięcie żądanej kolorystyki wymagałoby edycji kilku, a czasami i kilkunastu, selektorów css dla każdego jednego typu pola. Nie da się więc ukryć, że podejście sassowe jest zdecydowanie szybsze, prostsze i efektywniejsze.

Bezpośrednia podmiana w pliku _variables.scss

Drugi sposób, aczkolwiek niepolecany, to edycja wartości zmiennych bezpośrednio w plikach biblioteki. Plik odpowiedzialny ze motyw kolorystyczny to _variables.scss, który można znaleźć pod ścieżką node_modules/materialize-css/sass/components/_variables.scss. Domyślnie, interesująca nas część pliku wygląda tak:


// 1. Colors
// ==========================================================================

$primary-color: color("materialize-red", "lighten-2") !default;
$primary-color-light: lighten($primary-color, 15%) !default;
$primary-color-dark: darken($primary-color, 15%) !default;

$secondary-color: color("teal", "lighten-1") !default;
$success-color: color("green", "base") !default;
$error-color: color("red", "base") !default;
$link-color: color("light-blue", "darken-1") !default;

Definiowanie kolorów w tym pliku różni się o tyle, że kolory są tworzone poprzez funkcję color(), która przetwarza dane zmienne na wartość kolorystyczną. W ten sposób, nie musimy podawać wartości w formacie RGB – wystarczy, że podamy nazwę koloru (których listę znajdziemy w dokumentacji materialize.css) jako pierwszy argument, a jako drugi stopień rozjaśnienia / ściemnienia koloru (także na podstawie dokumentacji). Jeśli wolelibyśmy jednak użyć własnych kolorów (spoza dokumentacji), to każdy kolor musi być podany w formacie RGB. W przeciwnym wypadku, kompilator sass poinformowałby nas o błędzie. Własne kolory podajemy analogicznie, jak w poprzednim przykładzie, np. zamiast $primary-color: color("materialize-red", "lighten-2") !default podalibyśmy $primary-color: #000000, aby uzyskać kolor czarny. I to tyle.

Nadpisywanie wartości skompilowanego pliku .css

Trzeci, najmniej praktyczny, najtrudniejszy, i najbardziej czasochłonny sposób, to nadpisywanie wartości kolorystycznych dla każdego elementu osobno. Wymaga to zbadania danego elementu, skopiowanie jego selektora, a następnie nadpisanie koloru w osobnym pliku .css. Wpływa to niekorzystnie nie tylko na czytelność kodu, ale także na rozmiar paczki wrzucanej na stronę, ze względu na zduplikowane selektory. Dzięki temu, nie ukrywajmy, praca z biblioteką staje się bardzo frustrująca, gdyż nadpisanie koloru jednego rodzaju pola formularza często będzie wymagać od kilku do kilkudziesięciu linii css z użyciem kilku różnych selektorów (np. osobny do podkreślenia pola typu input, inny dla etykiety, itp.). Nawet, jeśli nie mamy jeszcze doświadczenia z kompilatorami css ani bundlerami, to szybciej (i na pewno opłacalniej) jest poświęcić parę godzin na naukę obsługi tych narzędzi, co przydaje się często i gęsto w pracy front-end developera, niż marnować kilka godzin na walkę z nadpisywaniem skompilowanego kodu css.

Podsumowanie

Spośród wszystkich przedstawionych tutaj sposób, zdecydowanie polecam ten pierwszy. Jest on najszybszy i najbardziej zgodny ze sztuką. Nie wymaga pisania dziesiątek linii kodu ani nie ingeruje bezpośrednio w pliki biblioteki materialize-css. Warto go stosować, nawet jeżeli nie mieliśmy wcześniejszego kontaktu z kompilatorami i bundlerami, gdyż pozwoli zaoszczędzić wiele godziny niepotrzebnej, frustrującej pracy. Co więcej, nie dość, że nauka bundlera zajmie krócej, to bedzie na pewno szybsza, przyjemniejsza i bardziej przydatna w przyszłości, niż umiejętność nadpisywania dziesiątek selektorów „na chama”.

Komentarze

Dodaj komentarz