Im więcej czytam o tym jak powinno się tworzyć kaskadowe arkusze stylów tym więcej myśle w bardziej ogólnych kategoriach o tym czym jest CSS i czym mógłby być. Nie da się ukryć, że CSS jest technologią prostą, pewnie zbyt prostą jak na współczesne potrzeby i dodatkowo zmienia się relatywnie wolno. Właściwie wszystko to co wymyślamy w kwestii różnorakich metodologii i technologii (np. preprocesorów) jest odpowiedzią na bolączki CSS i, mówiąc wprost, na jego braki. Jeśli się dobrze zastanowić to można z łatwością dojść do wniosku, że język arkuszy stylów nie przystaje do potrzeb współczesnego web design’u. Wiele osób może być tym zaskoczona bo przecież dzisiejsi deweloperzy tworzą rzeczy wręcz niewiarygodne, wielke serwisy internetowe i aplikacje o skomplikowanej strukturze front end’u to codzienność dla każdego użytkownika internetu, ale zapewne nikt nigdy nie zastanawiał się jak to wszystko powstaje i co jest używane do tego by takie serwisy mogły istnieć. Jeśli wziąć to wszystko pod uwagę od razu rodzi się pytanie: dokąd CSS powinien zmierzać?
Czym jest CSS?
Kaskadowe arkusze stylów (ang. Cascading Style Sheets, w skrócie CSS) to język służący do opisu formy prezentacji (wyświetlania) stron WWW.(…) Arkusz stylów CSS to lista dyrektyw (tzw. reguł) ustalających w jaki sposób ma zostać wyświetlana przez przeglądarkę internetową zawartość wybranego elementu (lub elementów) (X)HTML lub XML. (…) CSS został stworzony w celu odseparowania struktury dokumentu od formy jego prezentacji.
Źródło: Wikipedia.
Powyższą formułkę bez problemu mogła by na pewno powtórzyć każda osoba zajmująca się tworzeniem stron internetowych. W końcu jest to dość oczywiste…
Historia CSS byla burzliwa. Jeśli chcecie trochę poczytać o tym jak to wszystko się zaczynało to zachęcam do przeczytania wywiadu z Håkon Wium Lie. Natomiast to na czym chciałbym się teraz skupić to przyszłość. Przyszłość zaś najlepiej opisać w kontekście tego czym CSS nie jest a CSS nie jest językiem programowania.
„Programowanie” w CSS
Czasami zdarza się trafić na ofertę pracy zatutułowaną „Programista HTML”, ale pomijając tego typu kwiatki to chyba każdy z nas jest świadomy, że CSS i HTML nie są językami programowania. Może właśnie w tym tkwi problem? Toporna wręcz prostota języka, która powoduje, że nie ma on możliwości tak często bardzo potrzebnych podczas tworzenia współczesnego frontu aplikacji internetowych? Brak zmiennych, pętli, 'if’ów’ i wszystkiego tego co po prostu ułatwia pracę jest czasami na prawdę irytujący.
Nie wydaje się Wam, że to właśnie jest powód, dla którego taką popularność zyskują preprocesory? Dając deweloperom możliwości nieznane w czystym CSS są sposobem nie tylko na sprawniejsze pisanie kodu, ale też na lepszą organizację arkusza stylów. W ten sposób za jednym zamachem rozwiązujemy dwa problemy i możemy wcześniej iść na zasłużone piwo (po pracy oczywiście).
Osobiście chciałbym żeby ludzie z W3C pomyśleli o tym by rozwijać specyfikację CSS w tę właśnie stronę. Może niekoniecznie CSS stanie się językiem programowania, ale niech chociaż nabędzie kilku istotnych cech, które sprawią, że nasza praca będzie prostsza i przyjemniejsza. Wzorce w postaci preprocesorów już istnieją, więc temat nie powinien być zbyt trudny.
Konkluzja
Moja konkluzja jest dość prosta – nie wiem dokąd zmierza CSS ani czym stanie się za np. 5 lat. Mam jednak nadzieję, że twórcy specyfikacji zaczną powoli dryfować w stronę wizji, która dla mnie była by oznaką prawdziwych i realnych zmian w CSS. Mam też nadzieję, że te zmiany pojawią się na tyle szybko, że nie dojdzie do sytuacji, w której 'zewnętrzne’ technologie takie jak SASS lub LESS będą wręcz niezbędne dla sensownego pisania front endu.
Nie umiejąc samodzielnie odpowiedzieć na wiele pytań chciałem żeby ten artykuł stał się początkiem dyskusji mogącej wnieść coś nowego do tematu naszych wyobrażeń o CSS w przyszłości. Może Wy macie jakieś pomysły? Jak według Was powinna wyglądać przyszłość CSS? Zgadzacie się, że ewolucja inspirowana preprocesorami jest dobrym rozwiązaniem?
PS: Nasze pomysły spiszemy i podeślemy do W3C, więc warto się postarać!
Image courtesy of Vlado at FreeDigitalPhotos.net
Tagi: CSS3 • promowany • Rozmyślania
„Zmienne” w natywnym CSS, pomijając wsparcie na poziomie 10% (http://caniuse.com/#feat=css-variables), to trochę kulawy pomysł. Przy większej ilości styli już sam SCSS kompiluje się kilka ładnych sekund (oczywiście są tam mixiny, funkcje, pętle – samo obliczanie vertical rythm już trochę zabierze). Nie czuję niedosytu pracując z SASS/LESS/Stylus (pomijając to, że ten pierwszy najbardziej mi odpowiada).
Ja przyszłość CSS widziałbym bez W3C (wiem – słabo się to nadaje do wysłania :D). Mozilla, Google, Microsoft, Opera i Apple powinny porozumieć się i wspólnie powołać jakąś organizację, która szybciej wdrażała by kolejne specyfikacje i budowała spójne API – nie tylko zajęła by się CSS i HTML, może coś zrobiono by (przez „coś zrobiono” mam namyśli radykalnie ulepszono/przepisano) w końcu z API DOM.
>Ja przyszłość CSS widziałbym bez W3C
Nie tylko Ty. W3C jedynie sygnuje ostatnie specyfikacje… i tyle. HTML 5 nie powstał w W3C, połowa CSS3 to zbieranina quirków z Webkita, nowe JS-owe API powstały w Google (w tym Web Components) itd. W3C istnieje po to, żeby być odgórną instancją kontrolną – w końcu, żeby Sieć była dla wszystkich, musi mieć organ standaryzacyjny. I tylko dlatego wgl powstało coś takiego jak specyfikacja HTML 5 i szkic roboczy HTML 5.1 – w rzeczywistości jest to żywy standard, rozwijany przez WHATWG.
>Mozilla, Google, Microsoft, Opera i Apple powinny porozumieć się i wspólnie powołać jakąś organizację
No ale przecież istnieje od co najmniej 2007 – właśnie WHATWG. No i są inicjatywy samego community (dzięki którym mamy np. Service Workers), o sporej części których można poczytać na http://specifiction.org
>może coś zrobiono by (przez „coś zrobiono” mam namyśli radykalnie ulepszono/przepisano) w końcu z API DOM
W takim razie polecam zapoznać się z konceptem DOM4 (a raczej – DOM Living Standard) ;) https://dom.spec.whatwg.org/ W końcu zyskujemy sensowny engine selektorów CSS (metody query i queryAll), sensowne zbiory elementów (Elements będące subklasą Array – co jest możliwe od ES6 – więc nie trza będzie już się biedzić, jak przy NodeList) i projekty przepisania większości APIs na promises (patrz: Fetch API – https://fetch.spec.whatwg.org/ – które jest obiecankową i o wiele przyjaźniejszą wersją XHR; jest też wstępem do samodzielnego definiowania sposobów fetchowania zasobów)
W3C jest tylko po to, żeby postawić parafkę (królem jest community, W3C to tylko kanclerz)
Co do https://whatwg.org/ to nie tak sobie wyobrażam taką organizację. Raczej jako organizacja non-profit z zarządem wybieranym po udziałach danej firmy na rynku przeglądarek. Community jest super, ale na pewno nie jest to odpowiedni organ do wprowadzania PRZYZWOICIE SZYBKO jakichś odważnych zmian.
>Raczej jako organizacja non-profit z zarządem wybieranym po udziałach danej firmy na rynku przeglądarek.
No to mamy W3C… ;) Co do „po udziałach” – no to mamy Google :D Nie wiem czy istnieje sensowny sposób stworzenia takiej organizacji. Raczej upatrywałbym jakiejś szansy w demokratyzacji całego procesu standaryzacji (W3C/WHATWG wysuwa propozycje → community głosuje → wprowadzamy lub nie), jednak ze względów technicznych taki sposób nie przejdzie.
>Community jest super, ale na pewno nie jest to odpowiedni organ do wprowadzania PRZYZWOICIE SZYBKO jakichś odważnych zmian.
Czy ja wiem? Service workers były inicjatywą oddolną i bardzo szybko trafiły na stół sekcyjny W3C a dzisiaj są już zaimplementowane w Chrome. GH pokazuje, że repo ze specyfikacją powstało w lutym 2013. 1.5 roku dla wdrożenia tak specyficznej technologii jest IMO przyzwoitym wynikiem. W sumie jedynie prace nad HTML5 i ES6 się jakoś ciągną(eły) ;)
A kto mógłby głosować? Jak zdefiniować kto jest w community a kto nie? ;-) IMO w3c jest potrzebne, ale trzeba by zbliżyć do siebie te trzy frakcje, czyli organ standaryzacyjny, community i firmy od przeglądarek.
To się już dzieje na szczęście – w końcu W3C poszło po rozum do głowy i prace standaryzacyjne prowadzi na GH, gdzie każdy ma dostęp do każdej z opracowywanych specyfikacji.
>Nie da się ukryć, że CSS jest technologią prostą, pewnie zbyt prostą jak na współczesne potrzeby i dodatkowo zmienia się relatywnie wolno.
A to wada? Jedyne, czego brakowało w CSS2, nie licząc efektownych (ale nieefektywnych) dupsów to był flexbox/grid i media queries. 3/4 CSS3 to już po prostu rżnące GPU i CPU wodotryski, typu gradients, animations, transitions… Ok, ładnie to wygląda, ale 95% stron obeszłoby się bez tego (tak, jestem purystą). CSS3 nie wniósł nic ciekawego do mechanizmów rządzących CSS – przyniósł jedynie kilka efektów specjalnych w sferze prezentacji stron, np wprowadzając gradienty i border-radius w chwili, gdy Sieć przeszła ze skeumorphic na flat design… ;) CSS dlatego jest językiem Sieci, bo jest prosty – ta jego cecha pokonała arkusze stylów oparte na JS i była podstawą (niestety niewdrożonego) pomysłu na CAS – Cascading Attribute Sheets, gdzie przy pomocy składni CSS ustalałoby się wszelkie właściwości elementów na stronie.
>Przyszłość zaś najlepiej opisać w kontekście tego czym CSS nie jest a CSS nie jest językiem programowania.
Deliberowałbym :D http://lemire.me/blog/archives/2011/03/08/breaking-news-htmlcss-is-turing-complete/
>Nie wydaje się Wam, że to właśnie jest powód, dla którego taką popularność zyskują preprocesory?
I to, co obecnie robią, powinno pozostać ich działką. W3C pracuje nad „custom properties” w CSS i bardzo niepokojąco idzie to w stronę włożenia silniczka JS do silniczka CSS. Raz już to przerabialiśmy (słynne expression) i wypadło bardzo, bardzo słabo. Zresztą nawet jeśli skończyłoby się tylko na custom properties, to dam se rękę uciąć, że 95% producentów przeglądarek wdroży to poprzez JS (no bo przecież silnik jest gotowy, więc w czym problem?). Wydajność, wydajność i jeszcze raz wydajność: zmienne natywnie w CSS vs zmienne w preprocesorze – które lepsze? W preprocesorze, bo w CSS… nie istnieją. If w CSS – po co? Bo nie wiadomo jakie elementy będą na stronie i w zależności od tego zmieniać generowane style? Ale przecież serwer wie lepiej co będzie wyświetlał, więc może sam wygenerować potrzebny CSS. Itp itd. CSS powinien być prosty, bo tego się od niego wymaga. Jeśli zrobimy z niego kolejny język programowania (który pewnie i tak byłby kompilowany do JS, więc dostajemy potężne narzuty czasowe), to przeglądarki napuchną jeszcze bardziej i wczytywanie stron stanie się katorgą. Obecnie CSS i tak jest zbyt rozbudowany jak na mój gust a wszyscy, którzy zajmują się wydajnością, mówią wprost: nie używaj selektorów CSS3, bo wolno, nie używaj gradientów, bo tną, wymuszaj wsparcie GPU, bo będzie lipa… Serio chcemy do tych problemów dodać problemy typu memory leaking, niezdefiniowane zmienne… No i jak powiesz webdesignerom, że muszą się nauczyć programować? ;)
>PS: Nasze pomysły spiszemy i podeślemy do W3C, więc warto się postarać!
OMG, nie :D Przepraszam, ale to jeden z gorszych pomysłów jakie słyszałem. Do tego całego CSS-owego bajzlu (ponad 40 specek!) chcesz dokładać kolejne? Najpierw może przebij się przez to wszystko i dojdź do wniosku, że nie ma sensu nic tam dokładać, bo jest tam już wszystko a nawet o wiele więcej ;) Poza tym – po co do W3C? http://specifiction.org/ (a tam to już wgl dojdziesz do wniosku, że masz wtórne pomysły ;))
Pozwolę sobie jeszcze zalinkować mojego posta z ForumWeb.pl: http://www.forumweb.pl/porady-i-tutoriale-www/it-ciekawe-artykuly-z-branzy/480938#480938
Na samym jego dole, tam, gdzie jest kod, pozwoliłem sobie skomentować co nieco na temat CSS vars ;)
>A to wada? Jedyne, czego brakowało w CSS2, nie licząc efektownych
Nie o to mi chodziło. Co do gradientów etc. to się zgadzam, w większości to nice to have, ale nic co by tworzyło jakąś mega rewolucję. Pisząc o prostocie miałem na myśli właśnie brak funkcjonalności preprocesorów, których mi osobiście w CSS po prostu brak.
>Przyszłość zaś najlepiej opisać w kontekście tego czym CSS nie jest a CSS nie jest językiem programowania.
Deliberowałbym :D http://lemire.me/blog/archives…
Ok bardzo teoretycznie ;)
>I to, co obecnie robią, powinno pozostać ich działką. W3C pracuje nad
„custom properties” w CSS i bardzo niepokojąco idzie to w stronę
włożenia silniczka JS do silniczka CSS.
No to może ewolucja w stronę języka serwerowego? Wiem że to science fiction, ale tak sobie fantazjuje…
>No i jak powiesz webdesignerom, że muszą się nauczyć programować? ;)
Większość designerów zna Photoshopa tudzież Fireworks albo Sketcha a nie CSS (nawet ten 'prosty’ obecny) ;-D
>OMG, nie :D Przepraszam, ale to jeden z gorszych pomysłów jakie słyszałem.
Dziękuję, zawsze warto być w czymś 'naj’
Z drugiej strony jeśli jesteś na 'nie’ to Twoje opinie też moglibyśmy wysłać jako pomysł racjonalizatorski np. dlaczego nie warto pisać specki dla custom properties. Niestety dyskusji za dużo nie mieliśmy do tej pory, więc na razie możesz być spokojny do W3C nic nie wysyłamy
>Pisząc o prostocie miałem na myśli właśnie brak funkcjonalności preprocesorów, których mi osobiście w CSS po prostu brak.
Ale właśnie CSS ma być prosty. Od nieprostych rzeczy mamy JS ;) A CSS ma być prosty i wydajny. Dlatego funkcjonalność preprocesorów zostawiłbym w preprocesorach; inaczej do błędów JS doszłyby nam błędy w interpretowaniu CSS („Undefined variable” itd)
>No to może ewolucja w stronę języka serwerowego?
porneL swego czasu naskrobał PHP-owy preprocesor CSS. No ale właśnie: preprocesor. Bo nic innego „serwerowy CSS” by nie mógł robić (sam problem rozwiązywania media queries czy jednostek relatywnych jest ponad możliwości takiego języka).
>Większość designerów zna Photoshopa tudzież Fireworks albo Sketcha a nie CSS
No i to należałoby zmienić, bo później mamy %@!$%!^$ zamiast stron…
>Dziękuję, zawsze warto być w czymś 'naj’
Nie chodziło mi, żebyś odebrał to osobiście (za co przepraszam). Chodzi mi o to, że W3C i tak nie ma żadnej realnej władzy. Jak to pisałem niżej: community – król, W3C – kanclerz. I tak to działa. Żeby mieć realny wpływ na kształt CSS, trzeba mieć wpływ na środowisko. Tutaj bardziej się opłaca stworzenie „Unofficial draft” przy pomocy Respec i opublikowania tego na GH + specifiction.org, żeby ludzie mogli widzieć. A to już znanymi oddolnymi drogami w końcu trafiłoby do W3C. Natomiast zaczynanie od W3C zapewne zabiłoby pomysł.
>Z drugiej strony jeśli jesteś na 'nie’ to Twoje opinie też moglibyśmy wysłać jako pomysł racjonalizatorski np. dlaczego nie warto pisać specki dla custom properties.
A ja powiem tak: jak W3C już coś pisze, to to będzie napisane… ale niekoniecznie ktoś tego użyje ;) No bo – powiedz mi szczerze: napisałeś kiedyś coś w OWL? Albo w ITS? A może w SMIL? Nie? No właśnie ;)
>Ale właśnie CSS ma być prosty. Od nieprostych rzeczy mamy JS ;)
Może faktycznie jestem idealistą :P Czekam na bezbłędną technologię, która pozwoli mi używać funkcjonalności preprocesorów w arkuszu stylów
>No i to należałoby zmienić, bo później mamy %@!$%!^$ zamiast stron…
To raczej problem kiepskich koderów, a nie designerów. Ci trudzy myślą, że CSS gryzie
>Nie chodziło mi, żebyś odebrał to osobiście (za co przepraszam).
Nie obrażam się :)
>Czekam na bezbłędną technologię, która pozwoli mi używać funkcjonalności preprocesorów w arkuszu stylów
http://www.myth.io/ lub spójrz na generator SUIT CSS. Oczywiście obydwa polegają na JS, co gwałci wszelkie możliwe zasady PE
Myth znam akurat.
Mi by wystarczyło, żeby czysty CSS był wreszcie zgodny z zasadą DRY…