Obiektowy CSS – wolne żarty!

CSS jest wręcz niewdzięczny dla developerów – potrafi dużo, jednocześnie oferując nam tak niewiele. Od kilku lat istnieją dość nieudane próby zrobienia ze stylami czegoś więcej – powstają koncepcje frameworków, siatek i innych udziwnień, mających wnieść coś do świata kaskadowych arkuszów stylów. Tym razem niejaka Nicole Sullivan „z Denver, Colorado” postanowiła wprowadzić w obieg pojęcie obiektowo zorientowanego CSS. Brzmi co najmniej tak abstrakcyjnie, jak wskaźniki w PHP albo Wojciech Olejniczak w PiS.

Już na samym wstępnie trzeba zaznaczyć, że rewolucji nie ma. Postanowiono podeprzeć się chwytliwymi terminami, które ze stanem rzeczywistym mają naprawdę mało wspólnego. Otóż Pani Sullivan oparła swój manifest OOCSS na dwóch tezach:

Object Oriented CSS

Pozwolę sobie przetłumaczyć część pobudek, którymi kierowała się autorka, wymyślając OOCSS:

By zobrazować moją tezę piszę odpowiedniego frameworka, przede wszystkim jednak OOCSS jest zupełnie innym podejściem do CSS i kaskadowości. Bazuje na tradycyjnych dogmatach programowania, takich jak rozszerzalność obiektów, modułowość i przewidywalność kodu. Zaproponowane rozwiązania ocenione zostały przez pryzmat ich złożoności, innymi słowy: „co stanie się z wielkością Twojego CSS po dodaniu nowych stron i modułów?”.

Odpowiedzią na to pytanie jest dla wielu stron wymykający się spod kontroli rozrost kodu (spaghetti code), powodujący problemy z jego utrzymaniem. Ludzie często narzekają na CSS i słusznie – mimo że często jest to zwykłe pieniactwo, rozumiem ich frustracje.

Obecne metody pisania CSS wymagają od developera dużej wiedzy. By mianować się ekspertem CSS, trzeba spędzić wiele lat na kodowaniu. Nim nasz kod stanie się użyteczny, musimy okupić to nauką na własnych błędach. Proces developmentu we front-endzie skupia w sobie specjalistów na wielu poziomach wiedzy i obowiązków, mimo to nasze strony są niczym kolos na glinianych nogach. Możesz mieć świetnie dopracowaną dostępność, czy bezbłędny kod, ale kiedy dosiada się do niego ktoś zupełnie z zewnątrz, wszystko pada na łeb i szyję. Kod powinien być na tyle solidny, by nawet osoba nie znająca tajników CSS mogła w nim odnaleźć się bez problemów i złowieszczego wpływu na standardy kodowania, które przyjęliśmy wcześniej.

I tak, powstało 10 dobrych praktyk:

Mamy również 9 zagrożeń, których powinniśmy unikać jak ognia:

Bazując m.in. na nich, Nicole opublikowała framework CSS, opierający się na rozszerzalnych gridach oraz rozdzieleniu layoutu od treści i wyglądu od struktury kodu. Mamy więc stosowne grids.css, content.css i libraries.css (reset). Według frameworka OOCSS można stworzyć np. taki kod:

<div class=”line”>
	<div class=”unit size1of2 rss”> </div>
	<div class=”unit size1of2 gmail lastUnit”> </div>
</div>

który da nam jeden poziomy kontener (class=”line”),a w nim dwie sąsiadujące kolumny, mające 50% całej szerokości rodzica (size1of2). Mniej więcej na tej podstawie, autorka zaleca budowanie naszych stron – dzięki reużywalnym komponentom, takim jak choćby te zaprezentowane wyżej, powinniśmy budować wszystkie kontenery – w imię zasady, że większość z nich ma wspólne cechy. Zaleca się więc, by to kontenery (grids) definiowały szerokość, a zawarte w nich elementy contentu – wysokość (paddingi, marginesy, heighty). Do tego dochodzi customizacja przez dodawanie nowych klas do tagów, jeśli standardowy package jest niewystarczający. W gruncie rzeczy dobry pomysł – nie musimy przecież sugerować się zaproponowanymi przez autorkę szerokościami, wyglądem i czymkolwiek innym – framework ten ma ukazać, jak można wdrożyć w życie koncept OOCSS.

Trzeba uczciwie przyznać, że większość powyższych tez istnieje w świadomości koderów od kilku dobrych lat. Mimo to tylko nieliczni developerzy używają łatwych w utrzymaniu technik CSS. O ile więc nazywanie czegoś mianem „OOCSS” jest raczej żartobliwe w kontekście tego, co ten termin definiuje (przerost formy nad treścią!), tak nazwa ta swoimi gabarytami niepokojąco sugeruje, że należałoby rozważyć problemy, którym OOCSS stara się postawić.

Komentarze

1

Miło widzieć spełnione obietnice ;) Jesteś przeciwieństwem naszych polityków. OOCSS to szokująca sprawa, ale może być ciekawa…

2

„Trzeba uczciwie przyznać, że większość powyższych tez istnieje w świadomości koderów od kilku dobrych lat.”

I dla mnie to takie raczej ładne, ideologiczne zebranie wszystkiego w jedną, spójną całość. Co nie zmienia faktu, że chętnie to przejrzę ;d

„opublikowała framework CSS” – link się dobry nie zrobił ;>

3

używanie metody sprite w obrazkach

No dobra, a to dlaczego jest złe?

zx
4

Tiaa… chwytliwy tytuł prezentacji to podstawa. Szkoda że w środku niewiele nowości, a i nie ze wszystkim mogę się zgodzić.

Wiele wzorców projektowych przydaje się przy dłubaniu w CSS`ie, ale koncepcja frameworków CSS`owych jest dla mnie niezrozumiała i to ją wrzuciłbym najchętniej do zagrożeń. W obecnej formie imho to nie jest po prostu język do pisania fw :)

wzs
5

Wyedytowałem troche tlumaczenie, by bylo bardziej zgodne z tym, co autorka chciala przekazac. Takze mysle, ze w przypadku sprite chodzi po prostu o przesadne naduzywanie przy obrazkach, ktore nie powinny byc obrabiane ta metoda. ;-)

6

Dla mnie to jest lekka przesada. Trzeba sobie zadać pytanie czym jest CSS? A po odpowiedzeniu na nie zadać kolejne: czy CSS może być obiektowy? To z kolei rodzi kolejne pytanie: czy CSS jest językiem programowania? A jak już sobie odpowiemy na te pytania, to weźmy do ręki piwo, wypijmy je dla odwagi i karzmy Pani Nicole oraz wszystkim, którzy chcą z CSS robić niewiadomoco, iść w diabli. Tacy ludzie sztucznie nadmuchują CSS do balona, który ma być to jakimś frameworkiem, to znowu jakimś grid systemem. Boże święty! Przecież sam grid system, który ma być mega uproszczeniem dla CSS i koderów CSS (chociaż nie ma takiego czegoś jak KODER CSS, jest tylko osoba od front-endu ;)). Mają one być zachowaniem czasu, który byśmy stracili na kodowa… wróć! określanie w CSS kolumn, marginesów i tego typu pierdół. A tak naprawdę te systemy tylko śmiecą w naszym CSSie. Około 80% kodu, który jest napisany w takich plikach .CSS jest niepotrzebny, bo wręcz nieużywany.

A teraz jak to ma się do Pani Nicole? A no tak, że ona zakłada mega upraszczanie kodu, tak żeby każdy się w nim połapał, ale jeśli dla jednego elementu mam np. 4 różne klasy („class=”unit size1of2 gmail lastUnit””) to gdzie tu jest to uproszczenie? Jak przychodzi mi edytować szablon strony, który został wykonany za pomocą jakiegoś frameworku czy grid systemu to mnie nosi, bo zanim połapię się co gdzie jest w pliku CSS mija jakiś czas. Potem szukać wszystkich tych np. czterech klas w całym pliku .CSS i sprawdzać, co trzeba zmienić, żeby strona wyświetlała się tak jak chcę, to już zupełna masakra.

„Używaj resetów CSS z Yahoo UI” – a zmuście mnie! Z jakiej racji mam tego używać? Jeśli już używam jakichkolwiek resetów to tylko takich, które uważam za stosowne i które potrzebuję. A nie, że jakiś zewnętrzny reset mi z góry określa coś, czego nie chcę.

Siatek nie nauczę się kochać. Może nie tyle siatek co jakichś właśnie już gotowych grid systemów.

„kiedy dosiada się do niego ktoś zupełnie z zewnątrz, wszystko pada na łeb i szyję” – czy ja kogoś zmuszam do grzebania w moich projektach? Będę pisał tak, jak chcę, bądź jak wymaga tego zespół / zleceniodawca, a nie tak, żeby zadowolić wszystkich koderów na świecie.

Ponad to jeszcze, nie widzę nic złego w łączeniu stylów z konkretnymi identyfikatorami. Wedle tej zasady nie wolno mi np. ostylować elementów typu #top czy #footer, które wiadomo, że się nie powtórzą.

Ludzie! Zadajcie sobie jeszcze raz pytanie: CZYM JEST CSS? Frameworki i grid systemy wprowadzają więcej złego niż dobre. Co do grid systemów jeszcze – stawiają one pewne ograniczenia dla grafików, którzy nie zawsze są koderami i którzy o takim czymś pojęcia nie mają. Poza tym moga burzyć jaką twórczą koncepcję layoutu, która miałaby stanowić o niepowtarzalności i oryginalności designu.

Ot kropka i amen. :)

P.S. Jeśli możesz to powiększ lekko formularz do komentowania :)

7

@ludwik: święta prawda. nie mam nic do dodania.

Tomek
8

Uwagi w sumie słuszne, ale rzeczywiście przedstawione przesadnie. Z CSS można stworzyć bardzo wygodne narzędzie, a grid naprawdę się przydaje. Niemniej… bez przesady :) Dopiero gdy będziemy mieć CSS3 i wersja ta zostanie zaimplementowana w popularnych przeglądarkach, to będziemy mogli jakoś te idee rozwijać.

Tymczasem życzyłbym sobie, aby ktoś stworzyć prosty „framework” do tworzenia nawigacji. Ot, szybkiego przygotowywania różnych form menu – zakładek, poziomego, pionowego, itd. Żaden z obecnych frameworków CSS nie posiada czegoś tak podstawowego :)

9

twórz reużywalne komponenty

Reużywalność w CSS to mit. Teoria jest piękna, ale praktyka pokazuje, że rozdmuchane CSS stają się trudno utrzymywalne w wieloosobowym zespole. O ile w miarę wspólny HTML daje radę w umiarkowanie rozbudowanych projektach, to pięknie pomyślany CSS na początku, staje się potworkiem po kilku szybkich bug-fixach, change-requestach realizowanych przez różne osoby itp. Sprawdzalność starego KISS i w tej działce jest niepodważalna.

oddziel wygląd od struktury kodu vs. rozszerzaj style elementów poprzez nadawanie im kolejnych klas

Raz, że drugie przeczy pierwszemu. Dwa, że drugie przeczy C w nazwie CSS. W końcu trzy, że póki liczy się IE, dla którego aplikowalność stylu dla iloczynu klas jest nie do przejścia, podejście to zwielokratnia i liczbę klas dla poszczególnych elementów (tak równolegle, jak i w głąb drzewa), i te same deklaracje powtarzane dla kolejnych klas czy elementów.

Jestem fanem czystego i prostego kodu. Nie wierzę przy tym w sprawdzalność wspominanych w tekście systemów poza niewielkimi zespołami pracującymi przy umiarkowanie rozbudowanych projektach. Dobra utrzymywalność to realny czas i realne pieniądze. Przeformatowanie kawałka — dla przykładu — portalu nie może chyba wymagać przeszkolenia ze znajomości systemu CSS, którego przy budowie tego portalu użyto :-) Na inną okazję zostawię frustracje front-endowców, którzy takim kodem (napisanym przecież w dobrej wierze) muszą zarządzać.

bober
10

Rzeczywiście trudno zgodzić się z pewnymi tezami zaproponowanymi w prezentacji. Zapewne stworzenie arkuszy CSS według tych zasad jest sensowne w bardzo dużym projekcie gdzie większość elementów zostałaby wykorzystana. Jednak mniejszy projekt zawierałby taki nadmiarowy kod, o którym wspomniał ludwik. A przecież cel jaki chcemy osiągnąć to minimalna wielkość arkuszy CSS.

11

Framework CSS? OOCSS? :D Oplułem sobie monitor.
Po lekturze całego artykułu stwierdzam jednak, że pani Sullivan spadła z wysokich schodów ale uszkodziła sobie tylko połowę mózgu (czyt. zgadzam się z połową rad zawartych powyżej :)

Osobiście uważam, że głównie dla swojego dobra należy dbać o to aby oprogramowane (ocssowane) elementy strony dały się wykorzystać wielokrotnie, w różnych miejscach. Pociąga to za sobą konieczność zrezygnowania ze zbyt dużej ilości identyfikatorów na rzecz klas i właśnie korzystanie wieloklasowości (w czym przeszkadza IE6 który nie zrozumie .x.y).
Dobrze jest też oczywiście nie nadużywać zbędnych selektorów, czy pisać zrozumiałe nazwy klas.
Grid też wydaje się ciekawym pomysłem. Ale to głównie dlatego żeby później nie mieć takich kwiatków: {width:201px; height:18px; margin:3px 9px 12px 3px; itd}

Kiedyś spodobał mi się jeszcze pomysł podzielenia stylów na kilka plików z layoutem, kolorami i typografią. Rozszerzyć to można o predefiniowane kolory, wielkości i co tam jeszcze.

A tak serio, żeby CSS był sensownym narzędziem to potrzebuje zmiennych, lepszych selektorów (
#cos {
a {style dla #cos a}
em {style dla #cos em}
}
i czego tam jeszcze… Pewnie lepszego wsparcia :P

Reinmar
12

Z mojego praktycznego doświadczenia wynika, że żaden framework CSS nie jest na tyle elastyczny, żebym mógł z nim pracować. Oczywiście rady przekazane przez autorkę są po części słuszne, ale sama idea tworzenia frameworków, nie mówiąc już o OOCSS, jest na dłuższą metę skazana na porażkę.

W teorii, do wszystkich layoutów możemy użyć szablonów i powtarzalnych elementów, w praktyce nie możemy. Ponieważ każdy projekt jest inny, każdy inaczej wygląda.

Osobiście chciałbym mieć taki framework CSS ale dla formularzy, bez JS.

TYhagara
13

Niestety framework w obecnym stanie kompletnie nie nadaje się do użytkowania „na linii frontu”. Powód jest prozaiczny – autorka ułatwiła sobie sprawę z bugami wyświetlania grid systemu pod różnymi przeglądarkami stosując praktycznie wszędzie „overflow:hidden”. Nie muszę chbya mówić jak upierdliwe może to być w zastosowaniu praktycznym.

14

[...] do tworzenia stron internetowych znalazło kolejnego sprzymierzeńca w postaci organizacji W3C. Wczoraj object oriented CSS, dziś object oriented HTML! Nowa, obiektowa wersja języka HTML (zupełnie niezależna od [...]

15

CSS obiektowy – super. Niedługo HTML zacznie być językiem programowania, a na fremeworka do CSSa napisze się kolejnego, który jeszcze bardziej będzie ułatwiał robotę. Potem strona z suchym tekstem będzie zajmowała 1.5MB, z czego 1.49MB to biblioteki. Używanie takich udziwnień powoduje utratę panowania nad kodem. To tak jakby pisać strony WWW na rynek produkcyjny we frontpage…

16

reużywalne ?!

17

[...] i często występuje na różnych konferencjach branżowych – na przykład promując swój OOCSS. Wśród znanych kobiet front-endu należy wymienić Molly E. Holzschlag, pasjonatkę web [...]

18

ze źródła http://oocss.org/

lmao…

Dodaj komentarz

Dozwolone tagi: <blockquote>, <code>, <strong>