Walter Vasconcelos : Minigaleria

Najprostszym i najbardziej

oczywistym argumentem przemawiającym za oddzieleniem prezentacji od reszty strony jest uproszczenie i ułatwienie późniejszych modyfikacji - niezależnie czy będzie to drobna korekta kolorów czy całkowity lifting wyglądu strony.

XHTML i CSS

Słowem wstępu

Tomasz Staniak

Choć XHTML i CSS nie są tak naprawdę nowymi standardami, dopiero niedawno, wraz z upowszechnieniem się nowoczesnych przeglądarek, ich popularność zaczęła wzrastać.

Jak to jednak bywa w takich przypadkach - poziomy ich implementacji bywają różne, a popularność wynika raczej z powodu czysto ludzkiej przywary - "numerkomanii" (w ten sam sposób ludzie w domach instalują Windows 2003 Server bo ma wyższy numerek niż Windows 2000 czy XP), niż faktycznej świadomości zysków (oraz strat).

Większość developerów, wspieranych przez brak dobrego oprogramowania, tworzy strony, które tylko z pozoru (z poziomu najpopularniejszego walidatora - W3C) są zgodne z definicją standardu XHTML.

W serii artykułów w art&design magazine, postaramy się rozprawić z faktami i mitami dotyczącymi "nowej szkoły" oraz wskazać jak naprawdę powinno się robić strony zgodne ze standardami.

Nowi koledzy - XHTML i CSS

XHTML i CSS to wbrew pozorom nie są młode standardy. Jednak dopiero niedawno ich powszechne stosowanie stało się możliwe, głównie dzięki upowszechnieniu się takich przeglądarek jak Mozilla Firefox, Opera czy Konqueror/Safari.

Oba standardy mają kilka wersji.

XHTML

Wersje XHTML są nieco bardziej znane, gdyż na co dzień z nimi obcujemy - modyfikując chociażby DOCTYPE dokumentu.

Cztery wersje: XHTML 1.0 Basic, XHTML 1.0 Transitional, XHTML 1.0 Strict oraz XHTML 1.1. Istnieje także XHTML 1.0 Frameset, lecz powinno być to traktowane raczej jako ciekawostka. Do czasu wprowadzenia XFrames, ramki jak były, tak będą, niedostępne.

XHTML 1.0 Basic to standard zawierający minimalną ilość modułów pełnego XHTML, przeznaczony głównie dla czytników nie potrafiących obsłużyć pełnego standardu (np.: telefony komórkowe czy PDA).

XHTML 1.0 Transitional to standard przejściowy, dla tych, którzy chcieliby przejść na XHTML ale nie znają go w pełni. Zawiera wiele ułatwień, takich jak chociażby możliwość stosowania tagów zaniechanych w XHTML 1.0 Strict oraz mniej rygorystyczny box-model.

Niestety, zarazem wielu ludzi sądzi, że wystarczy zastosować XHTML 1.0 Transitional, dodać kilka slashy w <br> i już mamy XHTML. Jednym słowem - Transitional zamiast ułatwić przesiadkę, w wielu ludziach utrwalił przekonanie, że piszą dobry kod, w nowym standardzie.

XHTML 1.0 Strict jest zalecanym, bardziej rygorystycznym, standardem w oparciu o który będziemy prowadzić ten cykl artykułów. Stopniowo przechodząc przez wszystkie aspekty tworzenia poprawnych stron w XHTML (aż do, mamy nadzieję, XHTML 1.1)

Do czasu aż w najpopularniejszej (wciąż) przeglądarce - Internet Explorer - nie pojawi się możliwość obsługi dokumentów wysyłanych jako application/xhtml+xml standard XHTML 1.1 będzie głównie ciekawostką i standardem dla "starych wyjadaczy" i młodych autorów, którzy sądzą, że wystarczy wpisać XHTML 1.1 do DOCTYPE i niczym się to nie różni od XHTML 1.0.

Obecnie rozwijany jest także standard XHTML 2, który jednak nie będzie kompatybilny z XHTML 1 i HTML. Trwają także prace nad "HTML 5" - który jest, z grubsza, rozszerzeniem HTML 4.01.

CSS

CSS także dzieli się na 4 wersje: CSS 1, CSS2, CSS2.1, CSS3.

Początkujący często narzekają na brak spójności w interpretacji dokumentów XHTML pomiędzy przeglądarkami. Tak naprawdę nie narzekają na XHTML, lecz na CSS.

Różne przeglądarki obsługują różne fragmenty tych specyfikacji. Na dobrą sprawę nie ma jednej przeglądarki, która obsługiwałaby je wszystkie i w stu procentach.

Chociaż są aż cztery wersje CSS, to obecnie za obowiązujący standard, wciąż uważany jest CSS1, jako, że CSS2.1 został ponownie wycofany na czas wprowadzenia poprawek do specyfikacji.

Mamo, mamo, a Józio powiedział, że...

O XHTML krążą legendy, które, jak się przekonasz tworząc n-tą stronę z rzędu, mają się nijak do rzeczywistości.

Do najczęściej powtarzanych bzdur należą:

  1. XHTML, w stosunku do HTML, jest bardziej semantyczny;
  2. Jest bardziej kompatybilny;
  3. Szybciej się ładuje;
  4. Jest bardziej przyszłościowy;
  5. Jest bardziej dostępny dla osób niepełnosprawnych;
  6. XHTML to oddzielenie treści od formy, to beztabelkowe layouty;

Niestety, prawda jest taka, że:

  1. XHTML i HTML, pod względem ilości znaczników i atrybutów, są niemal identyczne;
  2. Wciąż najpopularniejsza przeglądarka - IE, nie umie prawdziwego XHTML;
  3. W rzeczywistości czas parsowania dokumentu HTML i XHTML jest tak nieznaczny, że mieści się w marginesie błędu;
  4. Nie. XHTML 2 nie jest kompatybilny z XHTML 1.x i HTML. Przesiadka na XHTML 2 prawdopodobnie będzie wymagała konwersji dokumentów;
  5. Chociaż faktem jest, że tworząc w XHTML 1.0 Strict, kod strony automatycznie spełnia niektóre z warunków WCAG, to dostępność i użyteczność (Usability and Accessibility) stron to inny temat - zdecydowanie głębszy;
  6. CSS działa doskonale także z HTML 4.01, a DIV'y są w specyfikacji HTML.

Pierwsza zawiedziona miłość - validator W3C nie jest zgodny z XHTML

Chociaż walidator W3C pozostaje wciąż "jedynym słusznym" i oficjalnym walidatorem kodu, to należy odnosić się do otrzymywanych wyników walidacji z pewnym dystansem.

Jest on, bowiem oparty o przestarzały Document Type Definition (DTD - napiszemy o nim więcej niebawem), który nie pozwala na sprawdzanie poprawności wielu elementów i nie wykrywa niektórych błędów.

Od dłuższego czasu, osoby, na co dzień zajmujące się tworzeniem stron WWW polecają inne walidatory:

Schema Validator: dostępny pod adresem schneegans.de/sv/
oraz eksperymentalny walidator Załącznika C specyfikacji XHTML:
qa-dev.w3.org/~bjoern/appendix-c/validator/

Ponadto trzeba pamiętać, że absolutnie żaden walidator nie sprawdza semantyki dokumentu i nie potrafi odróżnić kontekstu, w jakim stosujemy dane znaczniki.

Czy wiesz, że...?

Chociaż akapit wyżej argumentuję, że walidator W3C nie jest zgodny z XHTML, to posiada on jednak funkcje, o których mało kto wie, a które pomagają w tworzeniu poprawnych stron.

Po wejściu na stronę validator.w3.org należy wybrać opcję Extended interface. Uzyskamy wtedy dostęp do kilku dodatkowych opcji, z jakimi walidator będzie sprawdzał nasze strony.

Show Source
Po zaznaczeniu tej opcji, walidator wyświetli kod strony z podziałem na linie, oraz wskaże, w których liniach występuje błąd;
Show Parse Tree
Funkcja dla "power userów": wyświetla wynik parsowania dokumentu przez parser SGML;
Show Outline
Najważniejsza, z dodatkowych, funkcja wyświetlająca "drzewo" dokumentu HTML, zbudowane w oparciu o nagłówki występujące na stronie. Przydatne w przypadku świadomego tworzenia stron.

Czy naprawdę potrzebuję XHTML?

Przyjęło się mówić i pisać, że XHTML wprowadził beztabelkowe layouty, oddzielenie formy od treści, szersze wykorzystanie CSS i wiele innych, dobrych praktyk.

Niestety, niezupełnie jest to prawda, o czym już zdążyłem w tym artykule napisać.

Większość z tych technik doskonale działa w HTML 4.01, ale być może faktycznie potrzebne było wprowadzenie nowej technologii, by na zasadzie "wietrzenia", oczyścić atmosferę z błędów i utrudnień "starej szkoły".

Biorąc to pod uwagę, rodzi się pytanie: czy naprawdę potrzebuję XHTML?

Tak jak trener dobiera taktykę do posiadanych zawodników, tak Ty, twórca strony, powinieneś dobrać odpowiednią technologię do swoich potrzeb i oczekiwań.

Musisz wiedzieć, chociażby, że to mime-type determinuje odpowiedni doctype. Musisz także wiedzieć, że korzystanie z HTML 4.01 Transitional czy XHTML 1.0 Transitional w celu ukrycia mankamentów w kodzie - wcale nie świadczy najlepiej. Trzymaj się specyfikacji Strict (HTML 4.01 Strict i XHTML 1.0 Strict).

Jeśli wysyłasz stronę jako text/html - trzymaj się HTML 4.01 Strict/XHTML 1.0 Strict
Jeśli wysyłasz stronę jako application/xhtml+xml - stosuj XHTML 1.0 Strict/XHTML 1.1

Zapewne na początku będziesz wysyłał strony jako text/html bo jest to mniej "drakońskie". Oczywiście, stosowanie XHTML Strict, nawet w przypadku wysyłania go jako text/html ma swoje zalety:

Barokko z rokkoka, czyli oddzielenie treści od formy

Jednym z podstawowych problemów, z jakimi stykają się nowi użytkownicy chcący tworzyć strony w technologii XHTML i CSS jest oddzielenie treści strony od jej wyglądu.

Z pewnością, na pierwszy rzut oka, wydaje się być to bardzo nielogiczne: przecież pisząc coś w zeszycie od razu dobieramy kolory, pogrubienia, sposób pisania danych treści.

Jednak jak okaże się z czasem - w praktyce sprawdza się to doskonale.

Krok pierwszy - prezentacja

Najprostszym i najbardziej oczywistym argumentem przemawiającym za oddzieleniem prezentacji od reszty strony jest uproszczenie i ułatwienie późniejszych modyfikacji - niezależnie czy będzie to drobna korekta kolorów czy całkowity lifting wyglądu strony.

Co z tym się wiąże - musimy wydzielić z kodu strony absolutnie wszystko co wiąże się z jej wyglądem - jest czysto prezentacyjne.

Krok drugi - treść

Za oddzieleniem treści od reszty strony przemawia niemal dokładnie to samo, co za oddzieleniem prezentacji od reszty strony - łatwość modyfikacji i przejrzystość zawartości.

Wydzielenie treści (zawartości) strony, sprawia, że jej edycja staje się łatwa i prosta, zarazem nie ma ryzyka, że jakaś drobna zmiana zepsuje nam wygląd witryny na 12 podstronie. Nie musimy się także przedzierać przez gąszcz znaczników prezentacyjnych, które z reguły ograniczały czytelność kodu.

Ale czym treść strony jest tak naprawdę?

Najogólniej: treść to tekst, zawarty między znacznikami określającymi semantykę naszej strony: nagłówki (<h1> - <h6>), akapity (<p>), listy numerowane i nienumerowane (<ol>, <ul>), wyróżnienia (<strong>, <em>), cytaty (<q>, <cite>), fragmenty kodu (<code>, <var>).

Wbrew pozorom, to także wiersz - zawarty między <pre class="poezja"> - czy specjalny fragment kodu, zawarty między, chociażby: <pre class="css">.

Krok trzeci - struktura

Struktura to zbiór tych wszystkich elementów kodu strony, które pozostają po oddzieleniu treści od prezentacji.

Problem jednak w tym, że struktura dokumentu, jest zdecydowanie trudniejsza do zdefiniowania.

Dla przykładu:

<h1>Nagłówek</h1>

<p>Treść</p>

Jak już ustatliliśmy - jest to treść strony. Jest to zarazem także jej struktura, ponieważ użycie odpowiednich tagów, rozdziela zbitek liter, na mający semantyczny sens - nagłówek i akapit.
A biorąc pod uwagę fakt, że każda z przeglądarek ma zdefiniowany sposób interpretacji takich znaczników - można nawet uznać, że jest to także prezentacja.

Dochodzi nam jednak coś jeszcze - klasy i identyfikatory. Stanowią one nasze dziurki na sznurowadła, którymi następnie powiążemy wszystkie wymienione elementy w logiczną, i co więcej - atrakcyjną dla oka, całość. W końcu prezentacja bez struktury nie ma prawa działać.

Zgubiliście się już?

Zatem spróbujmy to uporządkować:

Dokąd nas to prowadzi?

Oddzielenie treści od struktury jest właściwie niemożliwe, albo raczej - niezalecane, jeśli tworzymy rozbudowane strony. Pozbawilibyśmy się w ten sposób możliwości łatwej manipulacji prezentacją treści.

Podobnie oddzielenie prezentacji strony od jej struktury jest niemożliwe: prezentacja bez struktury, do której się odnosi - nie istnieje. Nie ma sensu.

Ale, gdy już powiążemy w odpowiedni sposób, semantyczną treść z odpowiednią strukturą dokumentu, stworzymy ciało, na które będziemy mogli nałożyć ubranie - prezentację.

I chociaż niektóre, bardzo poważne, zmiany w prezentacji, mogą wiązać się ze zmianami w strukturze, to edycja treści nie wpłynie na modyfikację struktury.

Podsumowując

Chociaż na "papierze" to wszystko może wyglądać bardzo strasznie i skomplikowanie, to tak naprawdę jest bardzo logiczne i intuicyjne.

W najbliższych artykułach, będziemy starali się pokazać, do jakiego stopnia.

Tomasz Staniak