Wskazówki dotyczące struktury CSS w witrynach biznesowych (lub cokolwiek innego)

CSS i HTML są łatwe do zrozumienia. Jednak potrzeba wielu lat praktyki, aby poznać najlepsze podejścia architektoniczne podczas tworzenia witryn internetowych (i aplikacji) w sposób, który umożliwia ich ponowne użycie, konserwację w przyszłości i uszczęśliwia programistów.

Co rozumie się tutaj przez architekturę? To jest struktura kodu CSS. Sposób, w jaki dzielisz to na pliki, zasady stojące za nazwami klas, głębokość selektorów, sposób kaskadowania, co jest dziedziczone, jak konfigurujesz komponenty, strony, elementy i modyfikatory.

Trudno jest zastosować najlepsze praktyki do wszystkich tych składników witryny z setkami stron, różnymi typami treści, widokami ekranu, przypadkami skrajnymi, a także z rozważeniem dodania więcej na wierzchu i zmodyfikowania istniejących.

Twórz z komponentami, a nie ze stronami

Jest to jedna z głównych kwestii do rozważenia. Nie powinieneś stylizować na podstawie strony, na której jesteś. Nie twórz stylów .homepage… {}. Jeśli Twoja strona ma sekcję, nadaj jej styl. Dzięki temu możesz go ponownie wykorzystać na innych stronach. Jeśli masz przycisk, nadaj mu styl jak .button {} i użyj go ponownie w innym miejscu. Dotyczy wszystkich widoków.

Jest to najczęstsza rada i najlepsze podejście (jak dotąd), z którego możesz skorzystać.

Jak teraz radzisz sobie z różnicami dotyczącymi poszczególnych stron? Ponieważ jest to najczęstszy powód do stylizacji według strony? Cóż, jest kilka podejść:

Użyj modyfikatorów.

W „BEM” „M” oznacza modyfikator. To jest wygląd modyfikatora .block__child. Nawet jeśli nie używasz BEM, modyfikatory i tak istnieją. Jeśli istnieje odmiana komponentu lub sekcji, dodaj do niej modyfikator.

Idealnie byłoby, gdyby projektant był przemyślany i ograniczył różnice do minimum, aby kod był czysty, ale nie powinieneś bać się dodawać do niego więcej. Odmiany powinny idealnie nadpisać kilka właściwości i działać z tymi samymi znacznikami. To dobry sposób na podejście do komponentów w fazie HTML - dodaj potrzebne tagi i zachowaj ich spójność w całej witrynie. Nie dodawaj nowych z powodu klasy modyfikatora.

Stylizuj elementy dziecięce.

Innym podejściem jest styl oparty na kontekście. Przycisk jest zawsze przyciskiem, ma swoją klasę .button i wszystko, ale nadal możesz go dostosować, jeśli jest częścią innego komponentu. Generalnie nie jest to dobry pomysł, ponieważ tworzy niespójności, ale jest to również całkiem realistyczny przypadek użycia. W przeciwnym razie otrzymasz 20 modyfikatorów o dziwnych nazwach.

Style kontekstowe mają miejsce wtedy, gdy stylizujesz jeden komponent tylko wtedy, gdy jest on dzieckiem innego. Weźmy na przykład kartę artykułu. Domyślnie ma swoje style. Ale jeśli jest to część kolorowej sekcji z pewnym tekstem z boku, projekt wymaga, aby karta miała wokół siebie kilka innych elementów (takich jak animowane kształty itp.).

W takim przypadku styl należy nadać za pomocą selektora .parent .card {}. Będziesz musiał nadpisać tylko kilka właściwości, tak jak w przypadku modyfikatora. Kiedy to zrobisz, sama karta nie zwiększa złożoności swoich stylów, ale nadal będzie zachowywać się poprawnie w tym konkretnym przypadku krawędzi.

Kiedy się nad tym zastanowisz, zobaczysz, jak można to zastosować na podstawie poszczególnych stron. Jeśli w projekcie są jakieś dziwne przypadki skrajne i istnieją pewne drobne różnice w stosunku do standardowych widoków komponentów (i sposobu, w jaki wszystkie one ze sobą współdziałają), możesz stylizować tylko to za pomocą selektora .homepage {}. Pamiętaj tylko, aby używać tego oszczędnie. Z naszego doświadczenia wynika, że ​​takie style rzadko przekraczają kilka wierszy kodu.

Ważna uwaga do dodania: style oparte na kontekście NIE są ogólnie dobrą praktyką. W idealnym przypadku nie powinieneś tego nawet potrzebować. W większości przypadków będziesz mieć modyfikatory, które powinny działać wystarczająco dobrze. Mimo że w niektórych kompilacjach jest to realistyczne, zagłębianie się w dobry abstrakcyjny kod z surowymi regułami może być zbyt kosztowne.

Pracuj w sekcjach

Większość witryn biznesowych (a także wiele innych) dzieli treść na sekcje. Każda sekcja jest samodzielnym komponentem z klasą modyfikatora, która definiuje różne właściwości. Jedna sugestia dotycząca struktury klas będzie następująca:

• sekcja.section-container - może to być „nazwa komponentu”, jeśli chcesz, która zawiera spójne dopełnienia / marginesy lub cokolwiek innego.
• sekcja.section-border-top - to modyfikator. Nie używa to BEM, ale w razie potrzeby można go „przetłumaczyć” na obramowanie sekcji-kontenera.
• sekcja.section-welcome - to byłaby nazwa sekcji.

Znowu konwencja nazewnictwa nie ma tutaj znaczenia. Dzięki takim przekrojom uzyskasz swobodę dostosowywania stylów do komponentów wielokrotnego użytku w przypadkach krawędziowych utworzonych przez projekt (czy to z powodu niespójności, których należy przestrzegać, czy po prostu bardziej skomplikowanych widoków).

Separacja plików

Najprawdopodobniej użyłbyś Sassa lub innego podobnego preprocesora. Pod względem separacji plików istnieje wiele podejść, ale to, które przyjmujemy, ma następującą ogólną strukturę:

• Ogólne - Ogólne zwykle składa się z kodu konfiguracyjnego, takiego jak tworzenie siatki, style do tagów HTML, resetowanie / normalizator, niektóre style specyficzne dla CMS i podobne.
• Strony - style stron opisane powyżej. Najlepiej byłoby, gdybyś miał tutaj bardzo mało kodu.
• Komponenty - rdzeń kompilacji - znajdują się tutaj różne komponenty. Jedna wskazówka jest taka, że ​​możesz mieć „elementy” lub „różne”, które zmieściłyby mniejsze porcje komponentów w jednym pliku zamiast 80 plików. Większe oczywiście najlepiej umieścić w osobnych plikach.
• Układ - style globalne, na przykład w nagłówku, stopce, a następnie układach stron, modyfikatorach siatki i tak dalej.
• Wtyczki - wszystko zewnętrzne, które jest generowane przez wtyczkę, rozszerzenie lub cokolwiek innego. Fajnie jest je rozdzielić, ponieważ można ich użyć ponownie w innych projektach.

Utrzymuj selektory w czystości

Dobrym znakiem czystego kodu jest jego prostota. Żadnych dziwnych właściwości, wszystko ma swoje przeznaczenie, jest niskie wcięcie. Selektory „wyglądające inteligentnie”, gdy są niepotrzebne, nie sprawiają, że kod jest „fajny”. Jeśli możesz zastąpić coś takiego jak #container> .row div [rel = ”coś”] przez .rel-coś (wyobraź sobie, że jest to znacząca nazwa klasy), powinieneś po prostu nieco zaktualizować znaczniki. Celem tego jest uproszczenie wszystkiego.

Zachowaj niskie wcięcia. Rzadko musisz przejść więcej niż trzy poziomy. Zobaczmy na przykład klasę .entry:

.entry {...}
.entry-title {...}

Zobacz, że naprawdę nie ma potrzeby wcięcia .entry-title wewnątrz .entry. Później, kiedy dodasz modyfikator w dół pliku, możesz mieć .entry-modifier {} i .entry-modifier .entry-title {}

Dzięki takiemu podejściu nadpisywanie stylów w przyszłości jest znacznie łatwiejsze. Spójrzmy na inny typowy przykład: masz znaczniki nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Teraz, aby stylizować, potrzebujesz tylko:

.site-nav {} - składnik 1

.list-menu {} - składnik 2
.list-menu .list-item {}
.list-menu a {}

Jeśli masz więcej komponentów w środku, takich jak dodatkowe listy rozwijane, możesz zagnieździć je bezpośrednio w .list-menu. Nie musisz pisać .site-nav .list-menu .list-item .dropdown {} (4 poziomy), jeśli możesz mieć dwa poziomy .list-menu .dropdown {}

Napisz więcej abstrakcyjnych nazw klas dla modyfikatorów

Ten dotyczy łatwości konserwacji. Typowym przykładem, który można znaleźć w podobnych postach, byłoby ustawienie zmiennej koloru na $ red, zamiast tego można ustawić ją na $ primary lub $ secondary.

Powodem jest to, że gdy potrzebna jest zmiana w dalszej części wiersza, zmienna $ red wyświetli kolor niebieski. Bardziej sensowne jest to, że chcesz zmienić kolor podstawowy , a nie czerwony , prawda?

To samo dotyczy innych rodzajów kolorów i właściwości. Załóżmy, że masz linie oddzielające niektóre treści (np. Tag <hr>). Nazywasz to .line-dash, ponieważ jest przerywane. To ma sens. Ale potem nadchodzi zmiana i musi być kropkowana. Czy idziesz i zmieniasz nazwę na .line-dotted? To nie jest modyfikator, to jest komponent. Zamiast tego możesz nazwać go jako .line-separator. A jeśli chcesz być konkretny, możesz dodać modyfikator dla .dotted lub .dashed. Tego typu nazewnictwo często zajmuje najwięcej czasu podczas tworzenia witryny.

W podsumowaniu

Istnieje niezliczona ilość dobrych i złych praktyk. Jednym ze sposobów osiągnięcia lepszych wyników jest zdefiniowanie zasad i przestrzeganie ich. Trudno jest wymyślić takie zasady, więc jedną dobrą sugestią byłoby przeglądanie sieci i próba zebrania wszystkich możliwych informacji o architekturze, takich jak konwencje nazewnictwa, dobre praktyki, jak pisać łatwy w utrzymaniu kod i nie tylko.

Stworzenie dobrego kodu zajmuje dużo czasu i setki tysięcy wierszy kodu. Robiąc to wszystko, zawsze zadawaj sobie pytanie: „Czy taka skala?”, „Czy mogę jej użyć ponownie?”, „Czy nadpisałem za dużo?”, „Czy nazywanie tego w ten sposób ma sens?”. Im częściej to robisz, tym bardziej optymalne będą Twoje decyzje i tym bardziej poprawi się szybkość Twojej pracy.

Inwestycja w dobre podstawy zaowocuje mniejszą liczbą tam iz powrotem przy projektach, a wszelkie przyszłe zmiany, które będą musiały nastąpić, będą znacznie łatwiejsze do wdrożenia.