Style kaskadowe zorientowane obiektowo

W grudniu 2011 roku Louis Lazaris poruszył na łamach Smashing Magazine temat stylów kaskadowych zorientowanych obiektowo. Z technicznego punktu widzenia nie istnieje taki sposób zapisu lub definiowania arkuszy stylów kaskadowych. Spójrzmy jednak na tę kwestię nieco szerzej.

Sztuka tworzenia wydajnych i czytelnych arkuszy stylów to kwestia doświadczenia, ale i odpowiedniego podejścia. Według filozofii zorientowanej obiektowo reguły przygotowywane są pod kątem ponownego wykorzystania. Z tego względu nie powinny być ograniczane poprzez selektory kontekstu czy potomka. Jednak czy grupowanie wspólnych właściwości w klasach jest czymś nadzwyczajnym? Przecież to jedna z podstawowych zasad obowiązujących w CSS.

Wprowadzenie

Louis twierdzi, że separowanie wspólnych reguł, takich jak kolory, marginesy, czcionki i wiele innych daje zysk w sytuacji, gdy powtarzają się one w kontekście innych elementów na stronie. Zgadzam się, z tym stwierdzeniem choć określanie atrybutu class wielu elementom bywa zbyteczne. Teraz pojawia się kwestia wydajności i przejrzystości. Czy lepszy jest krótszy kod CSS (jeśli to w ogóle możliwe) czy jednak przejrzysta struktura dokumentu? Oba warianty mają swoje zalety i osobiście obstawałem przy drugim wyborze.

Niestety przy komercyjnych projektach struktura dokumentu i arkusze stylów rozrastają się równie szybko. Istotne jest rozsądne wyważenie podziału między obiema warstwami. Podejście zorientowane obiektowo przynosi korzyści przy naprawdę złożonych projektach. Nicole Sullivan jako pierwsza, która zaproponowała taki sposób tworzenia arkuszy stylów.

Globalne spojrzenie

Idąc dalej, tym tropem, uświadamiamy sobie jak wysokie wymagania wiążą się z pisaniem wydajnych stylów kaskadowych przez projektantów i koderów. Kod CSS jest zbyt wrażliwy na zmiany osób trzecich, szczególnie mało doświadczonych. Każda osoba wplata w pisane arkusze swoje wieloletnie nawyki, utarte schematy i osobisty tok rozumowania. Wówczas nasze rozbudowane style są praktycznie nieprzydatne dla innych osób.

Twórcy siatek CSS zrozumieli to wiele lat temu i stworzyli uniwersalne style dla układów wielokolumnowych. Ten kierunek jest zdecydowanie dobry, a zapoczątkował go 960 Grid System. Czy przeniesienie podobnego rozumowania na grunt pozostałych właściwości elementów stron internetowych jest możliwe?

Dobre praktyki

  1. Stwórz reguły, które wykorzystasz ponownie wykorzystasz.
  2. Niech twoje style będą semantyczne i jednolite.
  3. Niech moduły będą przezroczyste od wewnątrz.
  4. Bądź elastyczny.
  5. Pokochaj siatki.
  6. Ograniczaj selektory.
  7. Podziel strukturę i wygląd.
  8. Podziel kontenery i treść.
  9. Niech elementy struktury korzystają z przygotowanych klas.
  10. Używaj resetowania i czcionek ze stylów YUI.

Powyższe punkty zawarte w prezentacji Nicole są jasne, a przynajmniej w większości są jasne. Zdecydowanie zgadzam się z niektórymi, z paroma mniej, a kilku nie rozumiem. Podział reguł CSS na uniwersalne moduły skutkuje budowaniem wspólnego wyglądu elementów z mniejszych składników. Dzięki temu kolejne podstrony, właściwie nie potrzebują dodatkowych właściwości. Wspólny wygląd dla nagłówków, list i innych semantycznych elementów powinien być jednolity w obrębie całej strony, a zatem niech zostanie zdefiniowany w jednym miejscu. Rozdzielenie struktury i wyglądu stylów.

Podczas tworzenia stylów kaskadowych, częściej kieruje się rozsądkiem, niż emocjami. Z tego powodu nigdy nie używałem siatek. Mimo tego sformułowanie „Siatki określają szerokość, a zawartość wysokość elementów” jest prawdziwe. Rzeczywiście reguły typu .example {...} są bardziej użyteczne niż div.example {...}. Ale dlaczego wskazane jest korzystanie z gotowych stylów YUI? Czyżby były aż tak genialne?

Możliwe pułapki

  1. Style zależne od lokalizacji.
  2. Unikaj przypisywania klas do konkretnych elementów.
  3. Zapomnij o identyfikatorach dla stylów wewnątrz treści.
  4. Unikaj cieni i zaokrąglonych rogów dla nieregularnych teł
  5. Nie buduj map z wszystkimi obrazami.
  6. Unikaj wyrównania w pionie.
  7. Tekst jako tekst, a nie obraz.
  8. Nadmiarowość.
  9. Unikaj przedwczesnej optymalizacji.

Jeśli określone style są mocno zbliżone do siebie w obrębie danej strony to są niepraktyczne również w całym arkuszu stylów. Zdecyduj się na jednej wariant i stosuj go konsekwentnie. Niech jednolite reguły określają wygląd tych samych elementów. Nadpisywanie kolejnych właściwości w zależności o przodka elementu lub innych kryteriów jest kosztowne. Wówczas elementy zachowują się przypadkowo. Połączenie identycznych wspólnych reguł w różnych wariantach pozwala na szerokie zastosowanie.

Podsumowanie

Część z wymienionych punktów pokrywa się lub wzajemnie wyklucza w porównaniu z listą dobrych praktyk. Tak czy inaczej, wszystkie zalecenia traktujmy jako sugestie podczas procesu projektowania i tworzenia stylów kaskadowych. Całościowy zarys koncepcji jest nieco ogólny, a stosowanie poszczególnych wytycznych mocno uzależnione od samodyscypliny kodera.

Wszyscy wiemy, że CSS ma pewne braki, a internet rozwija się niezmiernie szybko. Jednak pisanie wydajnych arkuszy nie stanie się łatwiejsze wraz ze wsparciem CSS3 przez przeglądarki. Doświadczenie i sprawdzone schematy wciąż są ważne, co nie zwalnia nas z poszukiwania lepszych i optymalnych rozwiązań.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *