🌈🌈Zarządzanie kolorami w CSS🌈🌈

Co projekt, to inne metody zarządzania kolorami w CSS. Najczęściej reguł albo nie ma, albo są zbyt ścisłe, co powoduje sporo problemów. W poniższym wpisie postaram się przedstawić prosty przykład dotyczący tego, jak można ładnie poradzić sobie z kolorami w aplikacji.

Prosty przykład

Wyobraź sobie że zaczynasz niewielki projekt i dodajesz do niego kilka stylów. Z czasem widzisz, że pojawiają się niespójności jeśli chodzi o kolory. Przykładowo 

Mamy tu już 3 rozbieżności. Kolor można zadeklarować w hex za pomocą trzech lub więcej znaków, w klasie item dodatkowo zapisujemy background-color po prostu nazwą koloru, co jest odradzane. Dodatkowo, kolory można zapisywać nie tylko w wartościach hexadecymalnych, ale także w HSL, HSV i RGB. Wartości kolorów użyte w przykładzie są hipotetyczne :).

Problem pojawi się gdy będziesz miał coraz więcej kodu i każdy kolor dla każdego elementu będzie określany osobno za pomocą różnych wartości.

Dobrym wyjściem będzie wydzielenie kodu dotyczącego kolorów do custom properties.

Warto uspójnić sposób określania kolorów.

Na ten moment nie potrzebuję przezroczystości, dlatego ustawiam kolory jako hex zawierający zawsze 6 znaków. Kolory mamy teraz zgromadzone w jednym miejscu i możemy ich reużywać.

Pojawia się pytanie - jak bardzo rozdrabniać się w nazewnictwie kolorów. Przykładowo, w aplikacji na pewno będziesz potrzebował koloru do określania tego jak ma prezentować się tekst. Spotkałem się z rozwiązaniem polegającym na określaniu osobno koloru dla tabeli, sekcji czy nagłówków. Albo z osobnym stylowaniem każdej gwiazdki oznaczającej wymagalność, niezależnie od tego w którym miejscu się znajdowała.

Kolorów powstaje wtedy całe multum i w sekcji zmiennych pojawia się mnóstwo duplikacji. Moim zdaniem nie ma to zbyt dużego sensu. Jeśli elementy mają być ostylowane spójnie, to wystarczy im jeden wspólny kolor. 

Warto zastanowić się nad kwestią nazewnictwa kolorów. Można nazywać je semantycznie i wtedy nazwa odpowiada za to, co robi dany kolor. Tak zrobiłem w przedstawionym kodzie, określając kolor tła i kolor czcionki i dzieląc je na główne i podrzędne. Drugie podejście to po nazywanie koloru zielonego zielonym itd. 

Idąc dalej, w nowoczesnej aplikacji prawdopodobnie będziesz miał wybór trybu ciemnego i jasnego. Ponieważ mamy kolory wydzielone do jednej "dziedziny", możemy łatwo je odwrócić.

Niektóre elementy, jak linki, mogą potrzebować nawet 4 kolorów (link, visited, hover, focus) i tyle samo w trybie ciemnym. 

Jeszcze jedną zaletą takiego podejścia jest bardzo łatwa zmiana designu strony, jeśli pojawią się nowe wymagania ze strony klienta. Przy kolorach rozrzuconych po całej aplikacji, zmiana może zająć mnóstwo czasu i prawdopodobnie trzeba będzie przejrzeć cały kod CSS. Gdy kolory mamy w jednym miejscu, to kwestia poprawek tylko dla zmiennych.

Jeśli chcemy używać wariantu koloru, który już zdefiniowaliśmy, dobrym wyborem może być reużycie istniejącego koloru i zmiana go za pomocą filtru - https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function lub funkcji - przykładowo color-mix - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color-mix

Linter do CSS oraz na co zwracać uwagę przy review

Użycie lintera, takiego jak stylelint, umożliwi utrzymywanie spójnej koncepcji także w odniesieniu do css-owych kolorów. Przykładowo, można w nim wyłączyć używanie nazw kolorów i wymusić nazewnictwo jako pełny hex. Dzięki temu, późniejsza analiza kodu będzie łatwiejsza. Tego, by kolory deklarować jedynie w określonych miejscach linterem nie wymusimy, ale możemy to wychwycić w czasie review.

Podczas review starajmy się unikać sytuacji w którym jakiś kolor "wymyka" się z ustalonej konwencji, bo ktoś robił poprawkę na szybko. Przypominam tutaj teorie rozbitych okien - łamanie mniej ważnych norm w projekcie, powoduje jego degradację. Warto też spisać i udostępnić programistom reguły dotyczące kodu CSS, a podczas review, wymuszać ich stosowanie.

Obrazki z kodem wykonałem za pomocą chalk.ist