4 Składnia i podstawowe typy danych

4.1 Składnia

W tym podrozdziale została opisana gramatyka (i reguły zgodne z przyszłymi wersjami) wspólna dla wszystkich poziomów CSS (także CSS 2.1). W przyszłych aktualizacjach CSS ta podstawowa składnia będzie zachowana, przy czym mogą zostać zastosowane dodatkowe ograniczenia syntaktyczne.

Te opisy są normatywne. Ich uzupełnienie stanowią normatywne reguły gramatyczne opisane w dodatku G.

Wyrażenia "bezpośrednio przed" i "bezpośrednio za" w tej specyfikacji oznaczają, że pomiędzy nie występują żadne spacje ani komentarze.

4.1.1 Podział na tokeny

Wszystkie poziomy CSS — 1, 2 i przyszłe — korzystają z tej samej podstawowej składni. Dzięki temu aplikacje klienckie mogą przetwarzać (chociaż nie w pełni rozumieć) arkusze stylów napisane w poziomach CSS, które nie istniały jeszcze podczas tworzenia tych aplikacji. Projektanci mogą wykorzystać ten fakt przy tworzeniu arkuszy stylów działających we wcześniejszych wersjach aplikacji jednocześnie wykorzystując możliwości najnowszych poziomów CSS.

Na poziomie leksykalnym arkusz stylów składa się z szeregu tokenów. Poniżej znajduje się lista tokenów CSS. W definicjach zostały wykorzystane wyrażenia regularne w stylu analizatora leksykalnego Lex. Kody ósemkowe pochodzą z normy ISO 10646 ([ISO10646]). Podobnie jak w analizatorze Lex, jeśli zostanie znalezionych kilka dopasowań, za token uznawane jest najdłuższe z nich.

Definicje makr znajdujących się powyżej w nawiasach klamrowych ({}) są następujące:

Poniżej znajduje się podstawowa składnia CSS. W dalszych podrozdziałach opisano jak z niej korzystać. W dodatku G znajduje się bardziej restrykcyjna gramatyka, bliższa językowi CSS 2. Części arkuszy stylów, które mogą zostać przetworzone zgodnie z tą gramatyką, ale nie zgodnie z gramatyką w dodatku G to części, które zostaną zignorowane według zasad obsługi błędów analizy składniowej.

stylesheet  : [ CDO | CDC | S | statement ]*;
statement   : ruleset | at-rule;
at-rule     : ATKEYWORD S* any* [ block | ';' S* ];
block       : '{' S* [ any | block | ATKEYWORD S* | ';' S* ]* '}' S*;
ruleset     : selector? '{' S* declaration? [ ';' S* declaration? ]* '}' S*;
selector    : any+;
declaration : property S* ':' S* value;
property    : IDENT;
value       : [ any | block | ATKEYWORD S* ]+;
any         : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
              | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
              | DASHMATCH | ':' | FUNCTION S* any* ')'
              | '(' S* any* ')' | '[' S* any* ']' ] S*;

W gramatyce tej nie ma tokenów COMMENT (dzięki czemu jest bardziej czytelna), ale może występować dowolna ich liczba w dowolnym miejscu poza wnętrzem innych tokenów. (Należy jednak zauważyć, że komentarz umieszczony przed regułą @charset lub wewnątrz niej wyłącza tę regułę.)

Token S w powyższej gramatyce oznacza biały znak. Dozwolone są tylko następujące białe znaki: "spacja" (U+0020), "tabulator" (U+0009), "nowy wiersz" (U+000A), "powrót karetki" (U+000D) oraz "wysuw strony" (U+000C). Inne znaki podobne do spacji, jak "długa spacja" (U+2003) i "spacja ideograficzna" (U+3000) nigdy nie są zaliczane do zestawu białych znaków.

Znaczenie danych, których nie da się podzielić na tokeny lub przeanalizować pod względem składniowym jest w CSS 2.1 niezdefiniowane.

4.1.2 Słowa kluczowe

Słowa kluczowe mają postać identyfikatorów. Słowa kluczowe nie mogą występować w cudzysłowach ("…" lub ‚…’). Zatem

red

jest słowem kluczowym, natomiast

"red"

słowem kluczowym nie jest. (Jest to łańcuch.) Przykłady kilku innych niedozwolonych przypadków:

width: "auto";
border: "none";
background: "red";

4.1.2.1 Rozszerzenia niestandardowe

Identyfikatory w CSS mogą zaczynać się znakiem ‚-‚ (myślnik) lub ‚_‚ (znak podkreślenia). Słowa kluczowe i nazwy własności zaczynające się od znaków -‚ i ‚_‚ są zarezerwowane dla rozszerzeń producentów. Rozszerzenia producentów powinny być wyłącznie w jednym z następujących formatów:

'-' + identyfikator producenta + '-' + znacząca nazwa
'_' + identyfikator producenta + '-' + znacząca nazwa

-moz-box-sizing
-moz-border-radius
-wap-accesskey

Jest zagwarantowane, że w żadnej aktualnej ani przyszłej wersji CSS żadna własność ani żadne słowo kluczowe nie będzie zaczynać się od myślnika lub znaku podkreślenia. Dlatego typowe implementacje CSS mogą nie rozpoznać takich własności i zignorować zgodnie z zasadami postępowania z błędami analizy składniowej. Ponieważ jednak myślnik i znak podkreślenia występujące na początku należą do gramatyki, implementatorzy CSS 2.1 zawsze powinni mieć możliwość użycia zgodnego z CSS analizatora składni, bez względu na to czy obsługują rozszerzenia niestandardowe, czy nie.

Autorzy powinni unikać rozszerzeń niestandardowych

4.1.2.2 Uwagi historyczne

Ten podrozdział jest nienormatywny.

W chwili pisania tego tekstu znane były następujące przedrostki:

4.1.3 Litery i wielkość liter

Poniższe reguły obowiązują zawsze:

• W składni CSS nie jest rozpoznawana wielkość liter w zakresie ASCII (tzn. przedziały [a-z] i [A-Z] są równoważne), z wyjątkiem części nie będących pod kontrolą CSS. Na przykład poza zakresem tej specyfikacji znajduje się rozpoznawanie wielkości liter w atrybutach HTML "id" i "class", nazwach fontów oraz identyfikatorach URI. W szczególności należy zauważyć, że w języku HTML nie ma znaczenia wielkość liter w nazwach elementów, natomiast w XML ma.
• W CSS, identyfikatory (wliczając nazwy elementów, klasy i identyfikatory w selektorach) mogą składać się ze znaków [a-zA-Z0-9], znaków ISO 10646 o kodach od U+00A1 oraz myślników (-) i znaków podkreślenia (_). Nie mogą zaczynać się od cyfry ani myślnika, bezpośrednio po którym znajduje się cyfra. Identyfikatory mogą także zawierać znaki specjalne i dowolne znaki ISO 10646 w postaci kodu numerycznego (zobacz następny punkt). Na przykład identyfikator "B&W" może zostać napisany "B&W?" lub "B26 W3F".

  Należy zauważyć, że standard Unicode jest dokładnym odpowiednikiem ISO 10646 (zobacz [UNICODE] i [ISO10646]).

• W CSS 2.1 wsteczny ukośnik () oznacza trzy rodzaje sekwencji specjalnych.

  Po pierwsze, jeśli za wstecznym ukośnikiem znajdującym się w łańcuchu znajduje się znak nowego wiersza, jest on ignorowany (tzn. zostaje uznane, że łańcuch nie zawiera ani ukośnika, ani znaku nowego wiersza).

  Po drugie, znak ten anuluje znaczenie znaków specjalnych CSS. Za pomocą ukośnika można anulować specjalne znaczenie każdego znaku z wyjątkiem znaków znajdujących się w komentarzach CSS (oraz liczb szesnastkowych, znaku nowego wiersza, znaku powrotu karetki i wysuwu formularza). Na przykład """ jest łańcuchem składającym się z jednego podwójnego cudzysłowu. Programy wstępnie przetwarzające arkusze stylów nie mogą usuwać tych ukośników, ponieważ mogłoby to spowodować zmianę znaczenia tych arkuszy.

  Po trzecie, wsteczne ukośniki umożliwiają wstawianie do dokumentów znaków, których nie da się łatwo wstawić w inny sposób. W tym przypadku za wstecznym ukośnikiem znajduje się przynajmniej sześć cyfr szesnastkowych (0..9A..F), które reprezentują znak ISO 10646 ([ISO10646]) o takim numerze, który nie może wynosić zero. (W CSS 2.1 nie zdefiniowano, co się stanie, jeśli w arkuszu stylów znajdzie się znak o punkcie kodowym Unicode równym zero.) Jeśli po liczbie szesnastkowej znajduje się znak z przedziału [0-9a-fA-F], koniec tej liczby musi zostać wyraźnie oznaczony. Można to zrobić na dwa sposoby:

  1. stosując spację (lub inny biały znak): "26 B" ("&B"). W tym przypadku aplikacja kliencka powinna potraktować parę "CR/LF" (U+000D/U+000A) jako pojedynczy biały znak.
  2. wpisując dokładnie 6 cyfr szesnastkowych: "�00026B" ("&B")

  W istocie te dwie metody można stosować razem. Za szesnastkowym znakiem specjalnym ignorowany jest tylko jeden biały znak. Oznacza to, że aby za sekwencją specjalną użyć "prawdziwej" spacji, należy wpisać dwie spacje lub sekwencję specjalną dla spacji.

  Jeśli liczba nie należy do przedziału dozwolonego przez Unicode (np. "110000" to liczba większa od maksymalnej dozwolonej 10FFFF w aktualnym standardzie Unicode), aplikacja kliencka może zastąpić taki znak "znakiem zastępującym" (U+FFFD). Jeśli znak ma zostać wyświetlony, aplikacja powinna wyświetlić widoczny symbol, np. glif "oznaczający brak znaku" (por. 15.2, punkt 5).

• Uwaga: wsteczne ukośniki, gdzie jest to dozwolone, są zawsze uznawane za część identyfikatora lub łańcucha (tj. "7B" nie jest znakiem przestankowym, mimo że "{" tak, a "32" może znajdować się na początku nazwy klasy, podczas gdy "2" — nie).

  Identyfikator "test" jest dokładnie tym samym, co "test".

4.1.4 Instrukcje

Arkusz stylów na każdym poziomie CSS składa się z instrukcji (zobacz gramatykę powyżej). Wyróżnia się dwa rodzaje instrukcji: reguły ‚@’ i zbiory reguł. Instrukcje mogą znajdować się między białymi znakami.

4.1.5 Reguły ‚@’

Reguły ‚@’ zaczynają się od słowa kluczowego "at", czyli znaku ‚@’, bezpośrednio po którym znajduje się identyfikator (na przykład ‚@import’, ‚@page’).

W skład reguły ‚@’ wchodzi wszystko do najbliższego średnika (włącznie) lub wszystko do następnego bloku w zależności co wystąpi pierwsze.

Aplikacje klienckie CSS 2.1 muszą ignorować reguły ‚@import’ znajdujące się w blokach lub za nieignorowanymi instrukcjami innymi niż reguła @charset lub @import.

@import "subs.css";
h1 { color: blue }
@import "list.css";

@import "subs.css";
h1 { color: blue }

@import "subs.css";
@media print {
  @import "print-main.css";
  body { font-size: 10pt }
}
h1 { color: blue }

@import "subs.css";
@import "print-main.css" print;
@media print {
  body { font-size: 10pt }
}
h1 { color: blue }

4.1.6 Bloki

Początek bloku wyznacza otwierający nawias klamrowy ({), a koniec — odpowiadający mu zamykający nawias klamrowy (}). Między nawiasami mogą znajdować się dowolne tokeny. Nawiasy okrągłe (( )), kwadratowe ([ ]) klamrowe ({ }) muszą występować w dopełniających się parach i mogą być zagnieżdżane. Także pojedyncze (‚) i podwójne (") cudzysłowy muszą występować parami. Znajdujące się między nimi znaki są przetwarzane jako łańcuchy. Definicję łańcucha można znaleźć w podrozdziale Podział na tokeny powyżej.

{ causta: "}" + ({7} * ''') }

4.1.7 Zestawy reguł, bloki deklaracji i selektory

Zestaw reguł (nazywany również "regułą") składa się z selektora i bloku deklaracji.

Początek bloku deklaracji wyznacza otwierający nawias klamrowy ({), a koniec — odpowiadający mu zamykający nawias klamrowy (}). Między klamrami musi znajdować się zero lub więcej deklaracji oddzielonych średnikami (;).

Selektor (zobacz również podrozdział o selektorach) obejmuje wszystko to, co znajduje się przed otwierającym nawiasem klamrowym ({). Selektor zawsze występuje w towarzystwie bloku deklaracji. Jeśli aplikacja kliencka nie może przetworzyć selektora (np. nie jest to poprawny selektor CSS 2.1), musi go zignorować wraz ze znajdującym się za nim blokiem deklaracji (jeśli jest).

W selektorach CSS 2.1 specjalne znaczenie mają przecinki (,). Ponieważ jednak nie wiadomo czy w przyszłych aktualizacjach CSS przecinkowi nie zostaną nadane inne znaczenia, w przypadku wystąpienia jakiegokolwiek błędu w którejś części selektora, nawet jeśli reszta tego selektora może być poprawna według zasad CSS 2.1, cała instrukcja powinna zostać zignorowana.

h1, h2 {color: green }
h3, h4 & h5 {color: red }
h6 {color: black }

p[example="public class foo
{
    private int x;
    foo(int x) {
        this.x = x;
    }
}"] { color: red }

4.1.8 Deklaracje i własności

Deklaracja może być pusta lub składać się z nazwy własności, dwukropka (:) i wartości. Każdy z tych elementów może być otoczony białymi znakami.

Ze względu na sposób działania selektorów, jeśli istnieje więcej niż jedna deklaracja dla danego selektora, można je wszystkie zebrać w grupę deklaracji oddzielonych średnikami (;).

h1 { font-weight: bold }
h1 { font-size: 12px }
h1 { line-height: 14px }
h1 { font-family: Helvetica }
h1 { font-variant: normal }
h1 { font-style: normal }

h1 {
  font-weight: bold;
  font-size: 12px;
  line-height: 14px;
  font-family: Helvetica;
  font-variant: normal;
  font-style: normal
}

Nazwa własności jest identyfikatorem. W wartości może znaleźć się dowolny token. Nawiasy okrągłe ("( )"), kwadratowe ("[ ]") i klamrowe ("{ }") oraz pojedyncze (‚) i podwójne cudzysłowy (") muszą występować w uzupełniających się parach. Natomiast średniki nie należące do łańcuchów muszą być pisane ze znakiem specjalnym. Wszystkie wymienione rodzaje nawiasów można zagnieżdżać. Znaki znajdujące się w cudzysłowach są traktowane jako łańcuch.

Składnia wartości każdej własności jest określona osobno. Jednak zawsze wartości są zbudowane z identyfikatorów, łańcuchów, liczb, jednostek długości, procentów, identyfikatorów URI, kolorów itp.

Aplikacja kliencka musi ignorować deklaracje zawierające niepoprawną nazwę własności lub niepoprawne wartości. Każda własność CSS 2.1 ma własne warunki syntaktyczne i semantyczne dotyczące przyjmowanych wartości.

h1 { color: red; font-style: 12pt }  /* Niepoprawna wartość: 12pt */
p { color: blue;  font-vendor: any;  /* Niepoprawna własność: font-vendor */
    font-variant: small-caps }
em em { font-style: normal }

4.1.9 Komentarze

Początek komentarza wyznaczają znaki "/*", a koniec — znaki "*/". Komentarze mogą znajdować się w dowolnym miejscu między tokenami i nie mają wpływu na prezentację dokumentu. Komentarzy nie można zagnieżdżać.

CSS umożliwia także stosowanie w niektórych miejscach zdefiniowanych przez gramatykę ograniczników komentarzy SGML ("<!-" i "->"), ale nie wyznaczają one początku i końca komentarzy CSS. Zezwolono na ich używanie, aby dało się ukryć reguły stylistyczne wpisane w dokumenty HTML (w elemencie STYLE) przed aplikacjami klienckimi powstałymi przed ukazaniem się HTML 3.2. Więcej informacji na ten temat znajduje się w specyfikacji języka HTML 4 ([HTML4]).

4.2 Zasady postępowania z błędami analizy składniowej

W pewnych sytuacjach aplikacje klienckie muszą ignorować części niepoprawnych arkuszy stylów. W specyfikacji tej słowo ignorować oznacza, że aplikacja kliencka przetwarza niepoprawną część arkusza (aby odnaleźć jej początek i koniec), ale zachowuje się tak, jakby tego nie robiła. CSS 2.1 zastrzega prawo dla przyszłych aktualizacji do użycia dowolnej kombinacji własność:wartość i @-słowo kluczowe, które nie zawierają identyfikatora zaczynającego się od myślnika lub znaku podkreślenia. Implementacje muszą ignorować takie kombinacje (oprócz tych, które zostaną wprowadzone do CSS w przyszłości).

Aby w przyszłości było możliwe dodawanie nowych własności i wartości dla istniejących własności, aplikacje klienckie muszą przestrzegać poniższych zasad w następujących sytuacjach:

• Nieznane własności. Aplikacje klienckie muszą ignorować deklaracje zawierające nieznane własności. Jeśli np. aplikacja napotka poniższy arkusz stylów:

  h1 { color: red; rotation: 70minutes }
  

  zostanie on potraktowany, jakby wyglądał tak:

  h1 { color: red }
• Niepoprawne wartości. Aplikacje klienckie muszą ignorować deklaracje zawierające niepoprawne wartości. Na przykład:
  img { float: left } /* Poprawny kod CSS 2.1 */ img { float: left here } /* "here" nie jest poprawną wartością własności 'float' */ img { background: "red" } /* Słowa kluczowe nie mogą znajdować się w cudzysłowach */ img { border-width: 3 } /* Każda wartość określająca długość musi mieć jednostkę */
  Analizator składni CSS 2.1 przetworzyłby pierwszą regułę i zignorował resztę, tak jakby arkusz wyglądał następująco:
  img { float: left } img { } img { } img { }

  Aplikacja kliencka zgodna z nowszą specyfikacją CSS mogłaby zaakceptować również niektóre z tych obecnie odrzuconych reguł.

• Źle sformatowane deklaracje. Aplikacje klienckie muszą obsługiwać niespodziewane tokeny napotkane w czasie analizy składniowej. Czytają wówczas deklarację do końca postępując zgodnie z zasadami dopasowywania par (), [], {}, "" oraz ” i poprawnie obsługują znaki specjalne. Na przykład w źle sformatowanej deklaracji może brakować własności, dwukropka (:) lub wartości. Poniższe reguły są równoważne:
  p { color:green } p { color:green; color } /* Źle sformatowana deklaracja - brak znaku ':' i wartości */ p { color:red; color; color:green } /* Podobnie, jak wyżej */ p { color:green; color: } /* Brak wartości w deklaracji */ p { color:red; color:; color:green } /* Podobnie, jak wyżej */ p { color:green; color{;color:maroon} } /* Niespodziewane tokeny { } */ p { color:red; color{;color:maroon}; color:green } /* Podobnie, jak wyżej */
• Niepoprawne instrukcje. Aplikacje klienckie muszą obsługiwać niespodziewane tokeny napotkane w czasie analizy składniowej. Czytają wówczas instrukcję do końca postępując zgodnie z zasadami dopasowywania par (), [], {}, "" oraz ” i poprawnie obsługują znaki specjalne. Niepoprawna instrukcja może np. zawierać niespodziewaną klamrę zamykającą lub instrukcję @słowo kluczowe. Na przykład wszystkie poniższe wiersze zostaną zignorowane:

  p @here {color: red}     /* Zestaw reguł z niespodziewaną instrukcją "@here" */
  @foo @bar;               /* Reguła '@' z niespodziewanym słowem kluczowym "@bar" */
  }} {{ - }}               /* Zestaw reguł z niespodziewaną zamykającą klamrą */
  ) ( {} ) p {color: red } /* Zestaw reguł z niespodziewanym zamykającym nawiasem */
  

• Niepoprawne słowa kluczowe reguł @. Aplikacje klienckie muszą ignorować niepoprawne słowa kluczowe reguł ‚@’ i wszystko, co się za nimi znajduje do końca bloku zawierającego to niepoprawne słowo kluczowe lub do następnego średnika (włącznie) albo do następnego bloku ({…}), w zależności, co wystąpi pierwsze. Spójrzmy na poniższy przykład:

  
  @three-dee {
    @background-lighting {
      azimuth: 30deg;
      elevation: 190deg;
    }
    h1 { color: red }
  }
  h1 { color: blue }
  

  Reguła ‚@three-dee’ nie należy do specyfikacji CSS 2.1. Dlatego zostanie w całości (do trzeciej zamykającej klamry włącznie) zignorowana. Aplikacja kliencka CSS 2.1 zignoruje tę regułę, przez co arkusz stylów będzie wyglądał następująco:

  h1 { color: blue }

  Jeśli wewnątrz reguły ‚@’ znajdzie się niepoprawny fragment, który zostanie zignorowany (np. niepoprawna deklaracja w regule @media) nie oznacza to, że cała reguła zostanie uznana za niepoprawną.

• Nieoczekiwany koniec arkusza stylów.

  Aplikacje klienckie muszą zamykać wszystkie otwarte konstrukcje (np.: bloki, nawiasy, reguły, łańcuchy i komentarze) znajdujące się na końcu arkusza stylów. Na przykład:

  
    @media screen {
      p:before { content: 'Witajcie
  

  Powyższy arkusz zostałby potraktowany jako:

  @media screen { p:before { content: 'Witajcie'; } }

  przez zgodną ze standardem aplikację kliencką.

• Nieoczekiwany koniec łańcucha.

  Aplikacje klienckie napotykające koniec wiersza muszą zamykać łańcuchy ale odrzucać konstrukcje (deklaracje lub reguły), w których takie łańcuchy zostały znalezione. Na przykład:

  
        p {
          color: green;
          font-family: 'Courier New Times
          color: red;
          color: green;
        }
  

  Powyższy arkusz zostałby potraktowany jako:

  
        p { color: green; color: green; }
  

  Powodem tego jest fakt, że druga deklaracja (od ‚font-family’ do średnika za ‚color: red’) jest niepoprawna i zostanie odrzucona.

• Zobacz także Zestawy reguł, bloki deklaracji i selektory w celu uzyskania dodatkowych informacji na temat przetwarzania reguł w blokach deklaracji.

4.3 Wartości

4.3.1 Liczby całkowite i rzeczywiste

Niektóre typy wartościowe mogą mieć wartości całkowitoliczbowe (oznaczane <integer>) lub w postaci liczb rzeczywistych (oznaczane <number>). Liczby rzeczywiste i całkowite mogą być wyrażane wyłącznie w notacji dziesiętnej. Liczba typu <integer> (całkowita) składa się z przynajmniej jednej cyfry z przedziału od "0" do "9". Liczba typu <number> (rzeczywista) może być liczbą typu <integer> lub składać się z zera cyfr lub więcej, po których znajduje się kropka (.) i jedna cyfra lub więcej. Przed oboma typami liczb można stawiać symbole "-" i "+" określające ich znak. -0 jest równoważne z 0 i nie jest liczbą ujemną.

Należy zauważyć, że wiele własności, które przyjmują jako wartości liczby całkowite lub rzeczywiste ogranicza przedział akceptowanych wartości do określonego zakresu, często tylko do liczb dodatnich.

4.3.2 Długości

Długości odnoszą się do miar poziomych lub pionowych.

Format wartości długości (oznaczanej jako <length> w tej specyfikacji) składa się z następujących części: <number> (liczba z kropką dziesiętną lub bez), bezpośrednio po której znajduje się identyfikator jednostki (np.: px, em, itd.). Stosowanie jednostek po wartościach zerowych jest opcjonalne.

Niektóre własności pozwalają na używanie wartości ujemnych, ale to może skomplikować model formatowania. Ponadto mogą istnieć ograniczenia implementacyjne w tym zakresie. Jeśli dana wartość ujemna nie może zostać obsłużona, powinna zostać zamieniona na najbliższą obsługiwaną wartość.

Jeśli wartość ujemna zostanie ustawiona dla własności nie przyjmującej ujemnych wartości długości, deklaracja zostanie zignorowana.

Wyróżnia się dwa typy jednostek długości: względne i bezwzględne. Jednostka względna określa długość w odniesieniu do innej własności długościowej. Arkusze stylów, w których użyto jednostek względnych łatwiej dostosowują się przy przenoszeniu na różne media (np. z ekranu komputera do drukarki laserowej).

Do jednostek względnych należą:

• em: własność ‚font-size’ odpowiedniego fontu
• ex: własność ‚x-height’ odpowiedniego fontu
• px: wielkość piksela zależy od urządzenia

h1 { margin: 0.5em }      /* em */
h1 { margin: 1ex }        /* ex */
p  { font-size: 12px }    /* px */

Jednostka ‚em’ jest równa obliczonej wartości własności ‚font-size’ elementu, w którym została użyta. Wyjątkiem jest sytuacja, w której jednostka ta występuje w wartości własności ‚font-size’. Wówczas odnosi się ona do rozmiaru pisma elementu nadrzędnego. Jednostki tej można używać do określania miar poziomych i pionowych. (W tekstach z dziedziny poligrafii jednostka ta jest czasami nazywana szerokością poczwórną [quad-width].)

Jednostka ‚ex’ jest zdefiniowana przez pierwszy dostępny font elementu. Nazwa ‚x-height’ (wysokość-x) pochodzi od faktu, że jednostka ta często jest równa wysokości małej litery "x". Jednostka ta jest jednak zdefiniowana także dla tych fontów, w których nie występuje litera "x".

Wysokość x fontu można określić na różne sposoby. Niektóre fonty zawierają wiarygodne metryki dla wysokości x. Jeśli metryki takie są niedostępne, aplikacje klienckie mogą określić wysokość na podstawie wysokości glifu małej litery. Jednym ze sposobów jest sprawdzenie jak daleko glif małej litery "o" sięga za linię bazową pisma i odjęcie tej wartości od wierzchołka ograniczającego ją pola. W przypadkach, gdy określenie wysokości x jest niemożliwe lub niepraktyczne, powinna być stosowana wartość 0.5em.

h1 { line-height: 1.2em }

h1 { font-size: 1.2em }

W przypadku elementu głównego drzewa dokumentu (np. "HTML w języku HTML) jednostki ‚em’ i ‚ex’ odnoszą się do wartości początkowej własności.

Jednostki pikselowe zależą od rozdzielczości urządzenia prezentującego, najczęściej monitora komputerowego. Jeśli gęstość pikselowa urządzenia wyjściowego bardzo różni się od typowego monitora komputerowego, aplikacja kliencka powinna przeskalować wartości pikseli. Zalecane jest, aby jednostki pikselowe odnosiły się do całkowitej liczby pikseli urządzenia, co daje najlepsze przybliżenie piksela stanowiącego punkt odniesienia. Zalecane jest, aby piksel odniesienia stanowił wizualny kąt jednego piksela na urządzeniu o gęstości pikseli 96 dpi przy odległości od czytającego na wyciągnięcie ręki. Przyjmując długość ręki 70 cm, kąt ten wyniósłby około 0,0213 stopnia.

Zatem dla czytającego z odległości na wyciągnięcie ręki 1 px odpowiadałby wartości około 0,26 mm (1/96 cala). W przypadku druku w drukarce laserowej, której wydruk jest przeznaczony do czytania z mniejszej odległości (55 cm, około 21 cali), 1 px miałby rozmiar około 0,20 mm. W drukarce o rozdzielczości 300 punktów na cal (dpi) wartość ta mogłaby zostać zaokrąglona do 3 punktów (0,25 mm). W drukarce 600 dpi zaokrąglenie wyniosłoby 5 punktów.

Poniższe dwa rysunki ilustrują efekt patrzenia z różnych odległości na rozmiar piksela oraz wpływ rozdzielczości urządzenia. Na pierwszym rysunku odległość czytającego to 71 cm (28 cali), co daje piksel o rozmiarze 0,26 mm. Natomiast czytanie z odległości 3,5 m (12 stóp) wymaga piksela o rozmiarze 1,3 mm.

Na drugim rysunku obszar o wymiarach 1 x 1 piksel został pokryty jednym punktem w urządzeniu o niskiej rozdzielczości (ekranie komputerowym), podczas gdy w urządzeniu o wysokiej rozdzielczości (np. drukarce laserowej 400 dpi) ten sam obszar został pokryty 16 punktami.

Elementy potomne nie dziedziczą wartości względnych swoich rodziców, tylko wartości obliczone.

body {
  font-size: 12px;
  text-indent: 3em;  /* i.e., 36px */
}
h1 { font-size: 15px }

Bezwzględne jednostki długości są przydatne wyłącznie wówczas, gdy znane są fizyczne właściwości medium docelowego. Do jednostek bezwzględnych zaliczają się:

• in: cale — 1 cal wynosi 2,54 centymetra.
• cm: centymetry
• mm: milimetry
• pt: punkty — w CSS 2.1 punkt ma rozmiar 1/72 cala.
• pc: cycero — 1 cycero wynosi 12 punktów.

h1 { margin: 0.5in }      /* cale  */
h2 { line-height: 3cm }   /* centymetry */
h3 { word-spacing: 4mm }  /* milimetry */
h4 { font-size: 12pt }    /* punkty */
h4 { font-size: 1pc }     /* cycero */

Jeśli aplikacja kliencka nie może obsłużyć użytej długości, musi zastosować przybliżoną rzeczywistą wartość.

4.3.3 Wartości procentowe

Format wartości procentowej (oznaczanej w tej specyfikacji jako <percentage>) jest następujący: <number> (liczba), bezpośrednio po której znajduje się znak ‚%’.

Wartości procentowe zawsze są zależne od jakiejś innej wartości, np. długości. Każda własność pozwalająca na stosowanie wartości procentowych definiuje również wartość, do której się one odnoszą. Może to być wartość innej własności tego samego elementu, wartość własności elementu nadrzędnego lub wartość kontekstu formatowania (np. szerokość zawierającego bloku). Jeśli wartość procentowa zostanie ustawiona dla własności elementu głównego i odnosi się do oddziedziczonej wartości jakiejś własności, wartością wynikową będzie procent pomnożony przez wartość początkową tej własności.

p { font-size: 10px }
p { line-height: 120% }  /* 120% of 'font-size' */

4.3.4 Identyfikatory URL i URI

Wartości URI (Uniform Resource Identifier — zobacz [RFC3986] — do których zaliczają się URL, URN itp.) są w tej specyfikacji oznaczane jako <uri>. Notacja funkcyjna służąca do określania identyfikatorów URI w wartościach własności to "url()", np.:

body { background: url("http://www.example.com/pinkish.png") }

Format wartości URI jest następujący: ‚url(‚ + opcjonalne białe znaki + opcjonalny pojedynczy cudzysłów (‚) lub podwójny cudzysłów (") + identyfikator URI + opcjonalny pojedynczy cudzysłów (‚) lub podwójny cudzysłów (") + opcjonalne białe znaki + ‚)’. Oba użyte cudzysłowy muszą być takie same.

li { list-style: url(http://www.example.com/redball.png) disc }

Niektóre znaki znajdujące się w identyfikatorze URI nie umieszczonym w cudzysłowach, np. nawiasy, przecinki, białe znaki, pojedyncze cudzysłowy (‚) i podwójne cudzysłowy ("), muszą zostać opatrzone wstecznym ukośnikiem, aby powstał token URI: ‚(‚, ‚)’, ‚,’.

Zależnie od typu URI, może być również możliwe napisanie wymienionych znaków jako symboli zastępczych URI (gdzie "(" = %28, ")" = %29 itd.) zgodnie z dokumentem [RFC3986].

W celu utworzenia modułowych arkuszy stylów niezależnych od bezwzględnej lokalizacji zasobu, autorzy mogą użyć względnych identyfikatorów URI. Względne identyfikatory URI (zdefiniowane w dokumencie [RFC3986]) są rozwijane w pełne identyfikatory przy użyciu identyfikatora bazowego. W rozdziale 5 dokumentu RFC 3986 znajduje się definicja normatywnego algorytmu tego procesu. Dla arkuszy stylów CSS bazowym identyfikatorem URI jest identyfikator arkusza, nie dokumentu źródłowego.

body { background: url("yellow") }

http://www.example.org/style/basic.css

http://www.example.org/style/yellow

Aplikacje klienckie mogą na różne sposoby postępować z niepoprawnymi identyfikatorami URI lub identyfikatorami wskazującymi niedostępne lub nienadające się do użycia zasoby.

4.3.5 Liczniki

Liczniki są oznaczane przez identyfikatory, w których ma znaczenie wielkość liter (zobacz własności ‚counter-increment’ i ‚counter-reset’). W celu odwołania się do wartości licznika, należy zastosować notację ‚counter(<identifier>)’ lub ‚counter(<identifier>, <’list-style-type’>)’. Tokeny mogą być opcjonalnie oddzielone białymi znakami. Domyślny styl to ‚decimal’.

W celu odwołania się do sekwencji zagnieżdżonych liczników o takiej samej nazwie, należy zastosować notację counters(<identifier>, <string>)’ lub ‚counters(<identifier>, <string>, <’list-style-type’>)’ . Tokeny mogą być opcjonalnie oddzielone białymi znakami.

W celu dowiedzenia się, jak aplikacje klienckie muszą określać wartość lub wartości licznika, zobacz podrozdział "Liczniki zagnieżdżone i zakres" w rozdziale poświęconym treści generowanej. Sposób konwersji wartości licznikowych na łańcuchy przez własność ‚content’ został opisany w definicji wartości licznikowych tej własności.

W CSS 2.1 dostęp do wartości liczników można uzyskać tylko z własności ‚content’. Należy zauważyć, że wartość ‚none’ jest jedną z możliwości dla <’list-style-type’>: ‚counter(x, none)’ zwraca pusty łańcuch.

p {counter-increment: par-num}
h1 {counter-reset: par-num}
p:before { content: counter(par-num, upper-roman) ". "}

4.3.6 Kolory

Wartość typu <color> może być słowem kluczowym lub liczbowym określeniem składowych RGB koloru.

Lista słów kluczowych kolorów: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, orange, purple, red, silver, teal, white oraz yellow. Wartości liczbowe odpowiadające tym 17 kolorom są następujące:

Dodatkowo użytkownik może określić słowa kluczowe odpowiadające kolorom używanym przez pewne obiekty w środowisku użytkownika. Więcej informacji na ten temat znajduje się w podrozdziale o kolorach systemowych.

body { color: black; background: white }
h1 { color: maroon }
h2 { color: olive }

Model RGB jest stosowany do określania kolorów za pomocą wartości liczbowych. Wszystkie poniższe reguły określają ten sam kolor:

em { color: #f00 }              /* #rgb */
em { color: #ff0000 }           /* #rrggbb */
em { color: rgb(255,0,0) }
em { color: rgb(100%, 0%, 0%) }

W notacji szesnastkowej wartość RGB jest poprzedzona znakiem ‚#’. Po nim może znajdować się ciąg trzech lub sześciu cyfr szesnastkowych. Trzycyfrowa notacja RGB (#rgb) jest przekształcana na formę sześciocyfrową (#rrggbb) poprzez skopiowanie poszczególnych cyfr, nie dodanie zer. Na przykład wartość #fb0 zostanie rozwinięta do postaci #ffbb00. Dzięki temu kolor biały (#ffffff) można oznaczyć krótką notacją (#fff) oraz zostaje usunięta zależność od głębi kolorów wyświetlacza.

Format wartości RGB w notacji funkcyjnej jest następujący: ‚rgb(‚ + trzy wartości liczbowe oddzielone przecinkami (wartości całkowitoliczbowe lub procentowe) + ‚)’. Wartość całkowitoliczbowa 255 odpowiada wartości 100% i wartościom F lub FF w notacji szesnastkowej: rgb(255,255,255) = rgb(100%,100%,100%) = #FFF. W bezpośrednim sąsiedztwie wartości liczbowych mogą znajdować się białe znaki.

Wszystkie kolory RGB są określane w przestrzeni kolorów sRGB (zobacz [SRGB]). Różne aplikacje klienckie mogą odtwarzać kolory z różną wiernością. sRGB pozwala użyć jednoznacznej i dającej się obiektywnie zmierzyć definicji tego, jaki kolor powinien być, którą można odnieść do norm międzynarodowych (zobacz [COLORIMETRY]).

Zgodne aplikacje klienckie mogą ograniczać liczbę wyświetlanych kolorów poprzez dokonywanie korekcji gamma. sRGB określa współczynnik gamma wyświetlacza 2.2 w określonych warunkach. Aplikacje klienckie powinny tak dostosowywać kolory określone w CSS, aby w połączeniu z "naturalnym" współczynnikiem gamma urządzenia wyjściowego, był uzyskiwany efektywny współczynnik o wartości 2.2. Aby uzyskać więcej informacji, zobacz podrozdział o korekcji gamma. Należy zauważyć, że dotyczy to tylko kolorów określonych w CSS, np. obrazy powinny mieć własne informacje o kolorach.

Wartości z poza zakresu urządzenia powinny być obcinane lub odwzorowane w tym zakresie, gdy jest on znany: kolory czerwony, zielony i niebieski muszą zostać tak zmienione, aby mieściły się w zakresie obsługiwanym przez urządzenie. Aplikacje klienckie mogą wykonywać odwzorowania kolorów wyższej jakości z jednego zakresu na inny. Dla typowego monitora CRT, którego zakres kolorów pokrywa się z przestrzenią sRGB, poniższe cztery reguły są równoważne:

em { color: rgb(255,0,0) }       /* Zakres całkowitoliczbowy 0 - 255 */
em { color: rgb(300,0,0) }       /* Obcięcie do rgb(255,0,0) */
em { color: rgb(255,-10,0) }     /* Obcięcie do rgb(255,0,0) */
em { color: rgb(110%, 0%, 0%) }  /* Obcięcie do rgb(100%,0%,0%) */

Inne urządzenia, takie jak drukarki, mają inne zakresy niż przestrzeń sRGB. Niektóre kolory z poza zakresu 0..255 mogą dać się przedstawić (w zakresie danego urządzenia), podczas gdy niektóre kolory z tego zakresu mogą znajdować się poza zakresem urządzenia i mogą wymagać odwzorowania.

4.3.7 Łańcuchy

Łańcuchy mogą być pisane w podwójnych lub pojedynczych cudzysłowach. Podwójne cudzysłowy mogą występować wewnątrz innych podwójnych cudzysłowów pod warunkiem, że zostaną wstawione jako sekwencja specjalna (np. ‚"’ lub ’22′). To samo dotyczy pojedynczych cudzysłowów (np.: "’" lub "27").

"to jest 'łańcuch'"
"to jest "łańcuch""
'to jest "łańcuch"'
'to jest 'łańcuch''

Łańcuch nie może bezpośrednio zawierać znaku nowego wiersza. Aby wstawić do łańcucha znak nowego wiersza, należy użyć znaku specjalnego zastępującego znak nowego wiersza w normie ISO-10646 (U+000A), np. "A" lub "�0000a". Znak ten reprezentuje ogólne pojęcie "znaku nowego wiersza" w CSS. Aby zobaczyć przykład, przejdź do własności ‚content’.

Łańcuch można podzielić na kilka wierszy (np. z powodów estetycznych lub innych), ale w takim przypadku należy znak nowego wiersza opatrzyć wstecznym ukośnikiem. Na przykład dwa poniższe selektory są dokładnie takie same:

a[title="a not s
o very long title"] {/*...*/}
a[title="a not so very long title"] {/*...*/}

4.3.8 Nieobsługiwane wartości

Jeśli aplikacja kliencka nie obsługuje określonej wartości, powinna ją zignorować podczas analizy składniowej arkusza stylów, tak jakby była to niedozwolona wartość. Na przykład:

  h3 {
    display: inline;
    display: run-in;
  }

Aplikacja kliencka obsługująca wartość ‚run-in’ własności ‚display’ zaakceptuje pierwszą deklarację ‚display’, a następnie "nadpisze" ją drugą deklaracją ‚display’. Aplikacja nieobsługująca wartości ‚run-in’ przetworzy pierwszą deklarację ‚display’ i zignoruje drugą.

4.4 Reprezentacja arkusza stylów CSS

Arkusz stylów CSS jest sekwencją znaków z zestawu Universal Character Set (zobacz [ISO10646]). Dla celów transmisji i przechowywania znaki te muszą zostać zakodowane w jakimś kodowaniu znaków, które obsługuje znaki z zestawu US-ASCII (np. UTF-8, ISO 8859-x, SHIFT JIS itp.). Dobry wstęp do zestawów znaków i kodowania znaków znajduje się w specyfikacji języka HTML 4 ([HTML4], rozdział 5). Zobacz również specyfikację XML 1.0 ([XML10], podrozdziały 2.2 i 4.3.3 oraz dodatek F).

Jeśli arkusz stylów jest osadzony w innym dokumencie, np. w dokumencie HTML za pomocą elementu STYLE lub atrybutu "style", używa tego samego kodowania znaków, co ten dokument.

Jeśli arkusz stylów znajduje się w osobnym pliku, aplikacje klienckie muszą stosować następujące priorytety przy określaniu kodowania znaków arkusza stylów (kolejność od najwyższego do najniższego priorytetu):

1. Parametr HTTP "charset" w polu "Content-Type" (lub podobne parametry w innych protokołach)
2. BOM i/lub @charset (zobacz poniżej)
3. <link charset=""> lub inne metadane z mechanizmu dołączania
4. zestaw znaków arkusza stylów lub dokumentu (jeśli jest)
5. Przyjęcie UTF-8

Jeśli użyta zostaje reguła @charset, musi się ona znajdować na samym początku arkusza stylów. Nie może być przed nią żadnego znaku. (Jeśli dla użytego kodowania właściwe jest użycie znaku kolejności bajtów, może się on znajdować przed regułą @charset.)

Za regułą "@charset" podaje się nazwę kodowania znaków (w cudzysłowach). Na przykład:

Regułę @charset należy zapisywać dosłownie, tzn. ciąg 10 znaków ‚@charset "’ (małe litery, bez wstecznych ukośników), po którym znajduje się nazwa kodowania oraz ciąg ‚";’.

Nazwa zestawu znaków musi zgadzać się z nazwami opisanymi przez organizację IANA. Aby uzyskać pełną listę zestawów znaków, zobacz [CHARSETS]. Należy używać nazw zestawów znaków, które w spisie IANA są oznaczone jako "preferowane nazwy MIME" ("preferred MIME name")

Aplikacje klienckie muszą obsługiwać przynajmniej kodowanie UTF-8.

Wszystkie reguły @charset nie znajdujące się na początku arkusza stylów muszą być ignorowane. W przypadku wykrycia kodowania znaków przy użyciu znaku BOM i/lub reguły @charset, aplikacja kliencka powinna przestrzegać następujących zasad:

• Z wyjątkiem tego, co napisano w tych zasadach, wszystkie reguły @charset są ignorowane.
• Kodowanie jest wykrywane na podstawie początkowego strumienia bajtów arkusza stylów. W poniższej tabeli przedstawiono możliwe sekwencje początkowe bajtów (w zapisie szesnastkowym). Pierwszy wiersz, który zostanie dopasowany do początku arkusza stylów określa wynik wykrywania kodowania na podstawie znaku BOM i/lub reguły @charset. Jeśli żaden wiersz nie pasuje, nie da się wykryć kodowania na podstawie znaku BOM i/lub reguły @charset. Notacja (…)* oznacza powtórzenie, dla którego najlepsze dopasowanie to takie, które powtarza się najmniejszą możliwą liczbę razy. Bajty oznaczone jako "XX" służą do określania nazwy kodowania. W tym celu traktuje się je jako sekwencję znaków ASCII. Bajty oznaczone "YY" są podobne, ale muszą zostać przekodowane na ASCII, jak napisano. Aplikacje klienckie mogą ignorować pozycje tabeli, jeśli nie obsługują żadnego właściwego im kodowania.
  
  

  Bajty początkowe	Wynik
  EF BB BF 40 63 68 61 72 73 65 74 20 22 (XX)* 22 3B	jak określono
  EF BB BF	UTF-8
  40 63 68 61 72 73 65 74 20 22 (XX)* 22 3B	jak określono
  FE FF 00 40 00 63 00 68 00 61 00 72 00 73 00 65 00 74 00 20 00 22 (00 XX)* 00 22 00 3B	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność big endian)
  00 40 00 63 00 68 00 61 00 72 00 73 00 65 00 74 00 20 00 22 (00 XX)* 00 22 00 3B	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność big endian)
  FF FE 40 00 63 00 68 00 61 00 72 00 73 00 65 00 74 00 20 00 22 00 (XX 00)* 22 00 3B 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność little endian)
  40 00 63 00 68 00 61 00 72 00 73 00 65 00 74 00 20 00 22 00 (XX 00)* 22 00 3B 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność little endian)
  00 00 FE FF 00 00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 (00 00 00 XX)* 00 00 00 22 00 00 00 3B	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność big endian)
  00 00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 (00 00 00 XX)* 00 00 00 22 00 00 00 3B	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność big endian)
  00 00 FF FE 00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 (00 00 XX 00)* 00 00 22 00 00 00 3B 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność 2143)
  00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 (00 00 XX 00)* 00 00 22 00 00 00 3B 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność 2143)
  FE FF 00 00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 00 (00 XX 00 00)* 00 22 00 00 00 3B 00 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność 3412)
  00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 00 (00 XX 00 00)* 00 22 00 00 00 3B 00 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność 3412)
  FF FE 00 00 40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 00 00 (XX 00 00 00)* 22 00 00 00 3B 00 00 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność little endian)
  40 00 00 00 63 00 00 00 68 00 00 00 61 00 00 00 72 00 00 00 73 00 00 00 65 00 00 00 74 00 00 00 20 00 00 00 22 00 00 00 (XX 00 00 00)* 22 00 00 00 3B 00 00 00	jak określono (jeśli nie zostanie to określone, stosowana jest kolejność little endian)
  00 00 FE FF	UTF-32-BE
  FF FE 00 00	UTF-32-LE
  00 00 FF FE	UTF-32-2143
  FE FF 00 00	UTF-32-3412
  FE FF	UTF-16-BE
  FF FE	UTF-16-LE
  7C 83 88 81 99 A2 85 A3 40 7F (YY)* 7F 5E	jak określono, transkodowanie z EBCDIC na ASCII
  AE 83 88 81 99 A2 85 A3 40 FC (YY)* FC 5E	jak określono, transkodowanie z IBM1026 na ASCII
  00 63 68 61 72 73 65 74 20 22 (YY)* 22 3B	jak określono, transkodowanie z GSM 03.38 na ASCII
  analogiczne wzorce	Aplikacje klienckie mogą obsługiwać dodatkowe, analogiczne, wzorce, jeśli obsługują kodowania nie obsługiwane przez wzorce wymienione tutaj

• Jeśli kodowanie zostanie wykryte na podstawie pozycji w powyższej tabeli oznaczonych "jak określono", aplikacja kliencka ignoruje arkusz stylów, jeśli nie znajdzie na podstawie analizy składniowej odpowiedniej reguły @charset na początku strumienia znaków będących wynikiem dekodowania w wybranym zestawie znaków. Dzięki temu:
  • Reguły @charset powinny działać wyłącznie wówczas, gdy znajdują się w kodowaniu arkusza stylów.
  • Znaki kolejności bajtów są ignorowane jedynie w kodowaniach obsługujących znak kolejności bajtów.
  • Nazwy kodowań nie mogą zawierać znaków nowego wiersza.

Aplikacje klienckie muszą ignorować arkusze stylów o nieznanym kodowaniu.

4.4.1 Używanie znaków niedostępnych w określonym kodowaniu znaków

Może być konieczne użycie w arkuszu stylów znaków, których nie można zaprezentować przy użyciu bieżącego kodowania znaków. Znaki takie należy zapisywać jako specjalne referencje do znaków ISO 10646. Te specjalne referencje służą do tego samego celu, co numeryczne referencje do znaków w dokumentach HTML i XML (zobacz [HTML4], rozdziały 5 i 25).

Mechanizm stosowania znaków specjalnych należy stosować tylko wówczas, gdy takiej reprezentacji wymaga tylko kilka znaków. Jeśli większość znaków w arkuszu stylów musi być zapisana w ten sposób, należy zastosować bardziej odpowiednie kodowanie (jeśli np. arkusz stylów zawiera dużo znaków alfabetu greckiego, można użyć kodowania "ISO-8859-7" lub "UTF-8").

Procesory pośrednie używające innego kodowania znaków mogą przetłumaczyć te sekwencje specjalne na sekwencje bajtów tego kodowania. Procesory pośrednie nie mogą natomiast zmieniać sekwencji specjalnych anulujących specjalne znaczenie znaków ASCII.

Zgodne aplikacje klienckie muszą prawidłowo odwzorowywać na ISO-10646 wszystkie znaki z każdego kodowania znaków, które rozpoznają (lub muszą się zachowywać, jakby to robiły).

Na przykład arkusz stylów przesyłany jako ISO-8859-1 (Latin-1) nie może zawierać bezpośrednio greckich liter: "??????" (greckie: "kouros") musi zostać zapisane jako "3BA3BF3C53C13BF3C2".

<SPAN style="font-family: LFC beck">...</SPAN>

<SPAN style="font-family: Lübeck">...</SPAN>