Podstawy#

Wstęp#

Kaskadowe Arkusze Stylów (Cascading Style Sheets, w skrócie CSS) to język arkuszy stylów (style sheet language) używany do opisu semantycznych prezentacji (presentation semantics), czyli wyglądu i formatowania dokumentów utworzonych za pomocą języków znacznikowych. W większości przypadków CSS nadaje style stronom internetowym napisanym w HTML lub XHTML, ale język ten może być stosowany dla dowolnego dokumentu XML, np. SVG czy XUL.

CSS został utworzony w celu odseparowania struktury dokumentu od formy jego prezentacji (np. układu, kolorów i czcionek), dzięki czemu zachowana zostaje idea podziału na wiele warstw w tworzonych projektach. Separacja ta zwiększa zakres dostępności witryny, zapewnia większą elastyczność i kontrolę w opisie cech prezentacyjnych, umożliwia wielu stronom współdzielenie formatowania, i w końcu zmniejsza złożoność oraz powtarzalność kodu w strukturalnej treści (np. poprzez umożliwienie tworzenia tabelkowego designu).

CSS pozwala zaprezentować tę samą stronę na wiele sposobów dla różnych metod renderujących (ekran, dokument w druku, głosowy czytnik ekranowy, dotykowe urządzenie bazujące na Braille'u). Pozwala określić sposób wyświetlania strony w zależności od różnych parametrów, np. rozmiaru ekranu lub urządzenia, na którym jest oglądana. Stosowanie zewnętrznych arkuszy CSS daje możliwość zmiany wyglądu wielu stron naraz bez ingerowania w sam kod (X)HTML, ponieważ arkusze mogą być wspólne dla wielu dokumentów.

Rys historyczny#

Arkusze stylów istniały w tej czy innej formie (język DSSSL) już w początkowych fazach formowania SGML-a w 1980 roku. Kaskadowe Arkusze Stylów zostały opracowane jako środek do stworzenia spójnego sposobu przekazywania informacji o stylu dla dokumentów internetowych.

Wczesny HTML miał kilka poleceń pozwalających kontrolować wygląd dokumentu, niestety było ich zbyt mało by zaspokoić apetyt projektantów WWW. Z biegiem czasu dodawano do języka kolejne polecenia zwiększające kontrolę nad wyglądem strony, czyniąc jednocześnie HTML bardziej złożonym. Różnice w implementacjach przeglądarek internetowych, takich jak ViolaWWW oraz WorldWideWeb, utrudniały utrzymanie spójnego wyglądu w każdym programie, i w ostateczności użytkownicy mieli mniejszą kontrolę nad tym, jak treść strony internetowej była wyświetlana. Robert Cailliau (jeden z współtwórców WWW) chciał oddzielenia struktury od prezentacji, gdzie idealnym rozwiązaniem byłoby udostępnienie użytkownikowi różnych opcji i przenoszenia dla trzech różnych rodzajów arkuszy stylów: jeden dla drukowania, jeden dla prezentacji na ekranie, i jeden dla przyszłych pomysłów.

Aby zwiększyć możliwości prezentacyjne dokumentów webowych organizacja W3C brała pod uwagę 9 różnych języków arkuszy stylów. Spośród dziewięciu propozycji, dwie zostały wybrane jako podstawa tego, czym stało się w późniejszym czasie CSS: Cascading HTML Style Sheets (CHSS) i Stream-based Style Sheet Proposal (SSP). CHSS, który ma pewne podobieństwa do dzisiejszego CSS, został zaproponowany przez Håkon Wium Lie w październiku 1994 roku. W tym samym czasie Bert Bos pracował nad przeglądarką o nazwie Argo, w której wykorzystywał własny język arkuszy stylów o nazwie SSP. Lie oraz Yves Lafon dołączyli do Dave'a Raggett'a aby rozszerzyć przeglądarkę Arena o wsparcie CSS, która stała się testową aplikacją dla W3C. W późniejszym czasie Lie i Bos pracowali wspólnie nad standardem CSS (literka "H" została usunięta ze względu na możliwość stosowania stylów dla innych podobnych do HTML języków).

W sierpniu 1996 roku Netscape zaprezentował alternatywny język arkuszy stylów zwany JavaScript Style Sheets (JSSS), ale jego specyfikacja nigdy nie została ukończona i projekt został zamknięty.

Proces W3C i CSS#

W dokumencie "Cascading Style Sheets (CSS) Snapshot 2010" zamieszczono kilka podstawowych informacji na temat wszystkich specyfikacji, które razem tworzą aktualny stan Kaskadowych Arkuszy Stylów, na rok 2010. Jednym z ciekawszych opisów jest krótka charakterystyka procesu standaryzacyjnego dla CSS.

Zgodnie z dokumentem "World Wide Web Consortium Process Document", ścieżka rekomendacji dla dokumentów W3C obejmuje pięć poziomów stabilizacji, streszczonych poniżej:

Szkic Roboczy (Working Draft, WD) #

Wydany w czasie opracowywania specyfikacji, celem publikacji Szkicu Roboczego jest stworzenie migawki aktualnego stanu specyfikacji i zabieganie o wsparcie ze strony W3C i społeczności. Dokument jest uznawany za niestabilny i często jest niekompletny.

Ostatnie Wywołanie Szkicu Roboczego (Last Call Working Draft, LC lub LCWD) #

Poprzez publikację Ostatniego Wywołania Szkicu Roboczego, grupa robocza informuje, że uważa specyfikację za kompletną i wszystkie błędy zostały rozwiązane. Publikacja LC oznajmia, że specyfikacja ta będzie zmierzać w kierunku Kandydującej Rekomendacji, chyba że istotne błędy zostaną wychwycone. LC jest ostatnią szansą dla innych do zgłaszania błędów przed przejściem do CR.

Kandydująca Rekomendacja (Candidate Recommendation, CR) #

Poprzez publikację Kandydującej Rekomendacji, grupa robocza informuje, że rozwiązała wszystkie znane problemy i wierzy, że specyfikacja jest gotowa do implementacji.

Proponowana Rekomendacja (Proposed Recommendation, PR) #

Aby wyjść z CR i wejść to tego etapu, specyfikacja wymaga kompleksowego zestawu testów i sprawozdań z implementacji, potwierdzających, że każda funkcji w specyfikacji jest wdrożona interoperacyjnie w co najmniej dwóch niezależnych implementacjach. Wejście do stanu Proponowanej Rekomendacji sygnalizuje W3C, że wymogi te zostały spełnione. Kiedy W3C oficjalnie zatwierdzi specyfikację, to staje się ona Rekomendacją.

Rekomendacja (Recommendation, REC) #

Jest to ostatni etap. W tym momencie oczekuje się, że nie będzie więcej zmian.

Z doświadczenia grupy roboczej CSS wynika, że ścieżka rekomendacji nie jest liniowa. Szerszy przegląd wykonany w LCWD zazwyczaj skutkuje co najmniej kolejnym szkicem roboczym, a nawet kilkoma. W dodatku, wiele specyfikacji wchodzi do CR dwukrotnie, ponieważ testowanie implementacji zazwyczaj wykrywa poważne problemy w specyfikacji, i tym samym wraca ją do szkicu roboczego. Co więcej, naprawa nawet drobnych problemów wymusza na CR ponownego wejścia do stanu szkicu roboczego. W rezultacie, chociaż CSSWG ma jasną ideę stabilności specyfikacji CSS, jest to bardzo skomplikowane dla kogoś spoza grupy roboczej, aby dojść do identycznych wniosków w oparciu o oficjalny status specyfikacji. Motywacją grupy roboczej CSS do utworzenia tego opisu było wyjaśnienie innym osobom prawidłowego rozumowania poszczególnych etapów CSS.

Warto zapoznać się z nieco innym opisem ścieżki rekomendacji W3C umieszczonym na Wikipedii.

CSS1#

Pierwszą specyfikacją CSS, która stała się rekomendacją W3C, był dokument "Cascading Style Sheets, level 1" opublikowany w grudniu 1996 roku. Wśród jego funkcji najważniejszymi są:

CSS2#

W maju 1998 roku ukazała się specyfikacja "Cascading Style Sheets, level 2". Było to rozszerzenie CSS1 z szeregiem nowych możliwości, takich jak pozycjonowanie absolutne, relatywne i ustalone dla elementów, nakładanie elementów (właściwość z-index), pojęcie typów mediów, wsparcie dla dźwiękowych arkuszy stylów oraz tekstu dwukierunkowego, i nowe właściwości czcionki (np. cienie).

Nowa wersja zbyt pochopnie uzyskała status rekomendacji, ale tylko dlatego, że w tamtym czasie nie było jeszcze statusu kandydującej rekomendacji. CSS2 miał wiele problemów, które wypłynęły dopiero w późniejszym czasie.

CSS 2.1#

W3C szybko uznało specyfikację CSS2 za przestarzałą i w lutym 2004 roku udostępniło pierwszą kandydującą rekomendację w postaci dokumentu "Cascading Style Sheets Level 2 Revision 1" (lista zmian). Naprawiał on błędy CSS2, usuwał źle obsługiwane lub nie w pełni interoperacyjne funkcje oraz dodawał do specyfikacji już zaimplementowane rozszerzenia przeglądarek.

Po licznych poprawkach rozciągniętych na przestrzeli wielu lat standard CSS 2.1 uzyskał status rekomendacji dopiero 7 czerwca 2011 roku. Na chwilę obecną stanowi bazę do dalszego rozwoju języka CSS. Funkcje z CSS2, które porzucone zostały w CSS 2.1, mogą pojawić się w późniejszych modułach CSS (warto wspomnieć o poleceniach @font-face i text-shadow).

Wszystkie nowoczesne przeglądarki prawidłowo obsługują CSS 2.1, nawet nieszczęsny IE (chociaż do wersji 8 było z tym wiele problemów).

Dalszy rozwój#

Aktualnie trwają prace nad czymś, co wielu programistów określa jako "CSS3", a nawet "CSS4" (co nie do końca jest prawidłowe). W rzeczywistości nie jest to osobny język, dalej bazuje na CSS 2.1. Główną i w zasadzie najważniejszą ideą kryjącą się pod terminem "CSS3" jest wprowadzenie modularyzacji, która ułatwia i przyspiesza prace nad standardem (zamiast jednego dużego dokumentu rozwijanych jest wiele mniejszych z odpowiednimi poziomami). Każdy moduł dodaje nowe funkcjonalności lub zastępuje i rozszerza pewne części z CSS 2.1 (w takiej sytuacji poziom modułu zaczyna się od numeru 3, ale zachowana zostaje kompatybilność wsteczna). Kiedy prace nad modułem zostają zakończone, to zostaje on dołączony do istniejącego systemu CSS 2.1, włącznie z poprzednimi ukończonymi modułami.

Moduły tak naprawdę są rozwijane niezależnie, przykładowo moduł "Selectors Level 4" może być definiowany lub ukończony przed modułem "CSS Line Module Level 3". Niektóre moduły mogą być poziomu pierwszego, czyli są nowością, która nie występowała w poprzedniej specyfikacji CSS 2.1 (np. "CSS Flexible Box Layout Module Level 1"). Należy mieć świadomość tego, że konkretne oprogramowanie nie musi obsługiwać wszystkich modułów, np. przeglądarka głosowa (przeznaczona głównie dla osób niewidomych), nie potrzebuje obsługiwać właściwości, które są odpowiedzialne za formatowanie kolorów (Color), z kolei może chcieć obsługiwać styl mowy (Speech).

Nie wszystkie mechanizmy języka CSS zostaną ponownie zdefiniowane w modułach (a przynajmniej nie od razu), dlatego dokumentacja CSS 2.1 stanowi podstawę dla rozpoczynających przygodę z Kaskadowymi Arkuszami Stylów.

Modułów CSS nie należy mylić z profilami CSS (CSS Profiles). Profile są zazwyczaj podzbiorem jednego lub większej liczby poziomów CSS, które zbudowano dla danego urządzenia lub interfejsu użytkownika. Obecnie istnieją profile dla urządzeń przenośnych, drukarek oraz telewizorów. Profili nie należy mylić także z typami mediów (Media types), które zostały dodane w CSS2.

Obsługa przez przeglądarki#

Kilka miesięcy po opublikowaniu specyfikacji CSS1 (1996 rok) pojawiła się przeglądarka Internet Explorer 3 zapewniająca podstawową obsługę CSS1. Była to ważna cecha, która w czasach dominacji Netscape Navigatora, pozwalała przeglądarce Microsoftu wysunąć się na prowadzenie. Obsługa CSS1 była na tyle dobra, że można było porzucić niestandardowy znacznik <font> i rozpocząć eksperymentowanie z marginesami i innymi elementami układu strony. W praktyce projektanci napotkali liczne problemy związane z niekompletną i pełną błędów implementacją CSS1. Netscape w wersji czwartej zaimplementował CSS1 lecz, jak się okazało, także z licznymi błędami. Powszechnie uważano, że sam CSS jest wadliwy, a to skłoniło wielu projektantów do jego unikania. W efekcie uznanie CSS1 za oficjalny standard bardzo się opóźniło. Z dzisiejszej perspektywy można powiedzieć, że jest to język dość prosty a zarazem dający projektantowi wiele możliwości.

Dopiero w udostępnionym Internet Explorer 5 dla Macintosha, który ukazał się w marcu 2000 roku, CSS1 działało właściwie (zgodność większa niż 99%), co było zaskoczeniem dla Opery, która od 15 miesięcy liderowała w prawidłowej interpretacji CSS. Jednym z najpopularniejszych testów sprawdzających poprawną obsługę CSS1 był ACID1.

Mimo takiego usprawnienia wciąż istniały rozbieżności w pewnych obszarach, które generowały liczne błędy i dziwne zachowania. Wszystko to powodowało wiele utrudnień dla projektantów, którzy za wszelką cenę chcieli zachować spójny wygląd we wszystkich przeglądarkach i platformach. Na porządku dziennym było stosowanie różnych haków CSS pozwalających okiełznać cały ten bałagan.

W przypadku CSS2 i CSS 2.1 było jeszcze gorzej. Wieloletnia dominacja Internet Explorer 6 oraz Internet Explorer 7 uniemożliwiała powszechne wykorzystanie najnowszych funkcji, gdyż obsługa CSS w tych przeglądarkach była uboga i niejednokrotnie całkowicie błędna (podobnie zresztą jak DOM). Konkurencyjne przeglądarki były wydawane zdecydowanie częściej niż produkt Microsoftu, dzięki czemu błędy poprawiano na bieżąco, bez większej szkody i dodatkowego stresu dla programistów. Dopiero Internet Explorer 8 udostępniony w marcu 2009 roku mógł pochwalić się pełną obsługą CSS 2.1 (przynajmniej w teorii, test ACID2 przechodził, chociaż z ACID3 było gorzej).

Od tego momentu wszystko zaczęło iść w prawidłowym kierunku. Wraz z boomem na HTML5 twórcy przeglądarek internetowych wzięli się do solidnej pracy. Nowości pojawiają się szybciej, występuje zdecydowanie mniej rozbieżności między konkurencyjnymi programami, a samo stosowanie CSS nie nastręcza już tylu problemów i zszarpanych nerwów. Dotyczy to nawet Internet Explorera, którego wersja 9 zaczyna przypominać "prawdziwą przeglądarkę", chociaż pod względem najnowszych rozwiązań odstaje nieco od peletonu. Dysproporcja ta zniwelowana zostanie dopiero w IE11, i trzeba się z tego cieszyć, gdyż wersja ta zapowiedziana została także na system Windows 7, który prawdopodobnie stanie się drugim Windowsem XP (jeśli chodzi o popularność i "żywot" na rynku).

Rozszerzenia dostawców#

Aktualne przeglądarki internetowe w różnym stopniu obsługują najnowsze moduły CSS. Proces standaryzacyjny modułów jest długotrwały, dlatego nikt z implementatorów specjalnie się nie spieszy. Większość eksperymentalnych nowości udostępniana jest przy użyciu specyficznych rozszerzeń dostawców (vendor-specific extensions) zwanych potocznie prefiksami, które są unikatowe dla każdego silnika przeglądarek:

Najpierw powinno się definiować style z przedrostkami właściwymi dla przeglądarek, a dopiero w dalszej kolejności bez przedrostków. W ten sposób zyskamy pewność, że gdy w przeglądarkach ostatecznie usunie się obsługę prefiksów i wszystkie zaczną obsługiwać ustandaryzowane style CSS, to aplikacja nadal będzie działać prawidłowo:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
#element {
	-ms-box-shadow: 0 3px 5px #FFF;
	-moz-box-shadow: 0 3px 5px #FFF;
	-webkit-box-shadow: 0 3px 5px #FFF;
	box-shadow: 0 3px 5px #FFF;
}

Samo stosowanie prefiksów wiąże się z koniecznością tworzenia dłuższego kodu, stwarza zagrożenie faworyzowania konkretnego silnika, ale z drugiej strony umożliwia wprowadzenie osobnych korekt dla każdej przeglądarki (np. w przypadku niewłaściwej interpretacji eksperymentalnego polecenia).

Idea wprowadzenia prefiksów była szczytna (łatwa możliwość testowania przyszłych nowości), ale z biegiem czasu doprowadziła do wielkiego bałaganu w kodzie produkcyjnym. Sporo programistów stosowało głównie prefiks -webkit-, przez co inne programy zaczęły reagować również na niego (np. Opera i Firefox). Google przy premierze własnego silnika Blink postanowiło zrezygnować z wprowadzania kolejnych prefiksów, od tej pory eksperymentalne nowości można włączyć jedynie przy użyciu specjalnych flag (dostępnych pod adresem about:flags). Starsze prefiksy pochodzące z WebKita pozostawiono, ale będą one stopniowo eliminowane. Podobne stanowisko przyjęto także w Mozilli.

Szkodliwość stosowania prefiksów i działanie nowego podejścia bardzo dokładnie opisane zostało w następujących materiałach:

Rozszerzenia użytkowników#

Pomimo wielu interesujących nowości wprowadzanych z kolejnymi wersjami modułów, CSS wciąż zawiera pewne ograniczenia. Najważniejszymi bolączkami jest brak obsługi zmiennych, pętli, wyrażeń matematycznych, zagnieżdżeń w regułach czy selektora rodzica. CSS nie jest językiem programowania, dlatego też nie można wymagać od niego obsługi wszystkich mechanizmów przydatnych przy programowaniu.

W razie konieczności można skorzystać z gotowych preprocesorów CSS #. Są to projekty stosujące swój własny (wymyślony) język, bardzo podobny do języka CSS, za pomocą którego można uzupełnić braki w podstawowym CSS. Tak utworzony kod wystarczy skompilować (przy użyciu dedykowanych narzędzi) do postaci kodu CSS. Najpopularniejszymi tego typu rozwiązaniami będą SASS i LESS (są też inne). Można je zintegrować z systemami webowymi lub innymi popularnymi edytorami, tak by cała praca przebiegała w sposób dynamiczny. W przypadku tworzenia i utrzymywania dużych serwisów WWW stosowanie takich narzędzi może zaoszczędzić wielu godzin pracy.

Oprócz wyżej wymienionych istnieje cała masa ciekawych frameworków ułatwiających i przyspieszających pracę z kodem CSS. Niezależnie od funkcji i możliwości jakie oferują, to i tak gruntowna znajomość CSS będzie bardzo istotna (przynajmniej w zakresie podstaw).

Z biegiem czasu część z wymienionych ograniczeń zostanie wyeliminowana (np. obsługa zmiennych), ale nie wszystkie ubytki uda się wypełnić samym standardem CSS.

Pasek społecznościowy

SPIS TREŚCI AKTUALNEJ STRONY

Podstawy (H1) Wstęp (H2) Rys historyczny (H3) Proces W3C i CSS (H4) CSS1 (H4) CSS2 (H4) CSS 2.1 (H4) Dalszy rozwój (H4) Obsługa przez przeglądarki (H3) Rozszerzenia dostawców (H4) Rozszerzenia użytkowników (H4)