Obecnie w internecie obowiazuja dwa jezyki: starzejacy sie już HTML oraz zastepujacy go XHTML. Którego z nich używac? Jak przygotowywac strony WWW zgodne ze standardami?
Cztery proste zasady
Myśląc przyszłościowo o tworzeniu witryn WWW, warto przestrzegać czterech
prostych reguł. Po pierwsze należy sprawdzać poprawność każdego projektu. Można
do tego wykorzystać na przykład narzędzia dostępne na witrynie W3C. Jeśli do
witryny widocznej w internecie dodamy kod:
to wystarczy kliknąć podane hiperłącza HTML czy CSS, a poprawność kodu zostanie
zbadana. Jeszcze prościej poprawność dowolnej strony WWW sprawdzimy
wykorzystując Developer Toolbar Firefoksa. Walidacje ułatwiają narzędzia zawarte
w zakładce Tools. Można też wykorzystać wtyczkę Firefoksa o nazwie HTML
Validator. Narzędzie to działa offline.
Walidatory nie wychwycą wszystkich
możliwych błędów, nie należy ich zatem traktować jako ostatecznej wyroczni.
Pomogą jednak poznać błędy, które popełniamy. Nawet jeżeli nie zdołamy poprawić
ich w bieżącym projekcie, to i tak gra jest warta świeczki: kolejne projekty
rozpoczniemy dysponując większym doświadczeniem dotyczącym poprawności kodu HTML
i CSS.
Po drugie należy pracować w trybie standardów, a nie w trybie quirks
mode. Tryb pracy Firefoksa jest podany w oknie dialogowym Narzędzia | Informacje
o stronie w zakładce Ogólne.
Po trzecie należy stosować wersje strict. Każda
kolejna wersja HTML-a czy XHTML-a była coraz bardziej restrykcyjna. Pracując w
wersji strict nie tylko przestrzegamy najsurowszych obowiązujących zasad, ale
przygotowujemy się także na niespodzianki, jakie mogą się pojawić w kolejnych
wersjach XHTML-a.
Po czwarte starajmy się przygotowywać witryny, których
zawartość (pomiędzy znacznikami {html}
jest witryna, sprowadzi się do modyfikacji deklaracji DOCTYPE (lub ewentualnie
całego nagłówka strony, czyli wszystkiego powyżej {html}{/html}) oraz zmiany nagłówka
Content-type protokołu HTTP.
HTML czy XHTML?
Treść strony zawarta pomiędzy znacznikami{html}
{/html} oraz {hml}{/html} powinna być zgodna (przynajmniej w sensie walidatorów W3C) zarówno z językiem HTML 4.01 strict, jak i z językiem XHTML 1.0 strict. Niechlujne zamykanie znaczników, stosowanie znaków & zamiast encji, używanie liter dużych i małych w nazwach znaczników czy korzystanie z przestarzałych elementów to już internetowe średniowiecze.Wprawdzie ogromna większość witryn zawiera niepoprawny kod HTML, jednak były one przygotowywane w czasach, gdy standardy nie obowiązywały, a przynajmniej nie były tak popularne. Nikt nie poprawi osiemdziesięciu miliardów witryn WWW dostępnych w internecie. Należy zadbać o to, by nowo powstające witryny były coraz bardziej zgodne ze standardami, a starsze poprawiać w miarę możliwości.
Rozwiązanie 1
Język, nagłówek HTTP:
język: HTML 4.01 strict
Deklaracja DOCTYPE: HTML 4.01 strict
wysyłany zawsze jako text/html
brak deklaracji XML, zwykły dokument HTML
ZALETY:
- dostępny dla osób stosujących statyczne pliki .html (bez PHP i innych technik server-side)
- pełna zgodność ze standardami (pomijając {html}/>{/html})
- brak problemów przy przygotowywaniu wersji offline
- wersja offline identyczna jak online
- brak negocjacji zawartości
- brak cloakingu
WADY:
- staroświecki (?)
- brak możliwości skorzystania z walidacji XHTML przez przeglądarkę
Rozwiązanie 2
Język, nagłówek HTTP:
język: XHTML 1.0 strict
Deklaracja DOCTYPE: XHTML 1.0 strict
wysyłany zawsze jako text/html
brak deklaracji XML, zwykły dokument HTML
ZALETY:
- dostępny dla osób stosujących statyczne pliki .html (bez PHP i innych technik server-side)
- brak problemów przy przygotowywaniu wersji offline
- wersja offline identyczna jak online
- na oko „very cool” – strona w XHTML-u
- brak negocjacji zawartości
- brak cloakingu
WADY:
- niezgodne ze standardami
- wersja offline nie zgodna ze standardami
- wysyłanie XHTML zawsze jako text/html jest uznawane za szkodliwe
- brak możliwości skorzystania z walidacji XHTML przez przeglądarkę
Rozwiązanie 3
Język, nagłówek HTTP:
język: HTML 4.01 strict dostępny publicznie, XHTML 1.0 strict podczas pracy nad witryną
Deklaracja DOCTYPE: HTML 4.01 strict
wysyłany zawsze jako text/html
brak deklaracji XML, zwykły dokument HTML
W czasie tworzenia witryny (witryna niedostępna publicznie) stosujemy nagłówki XHTML, deklarację XML i Content-typeapplication/xhtml+xml. Wymaga to wymiany wyłącznie nagłówka strony WWW i protokołu HTTP.
ZALETY:
- pełna zgodność ze standardami (pomijając {html}/>{/html})
- brak problemów przy przygotowywaniu wersji offline
- wersja offline zgodna ze standardami
- wersja offline identyczna jak online
- możliwość skorzystania z walidacji XHTML przez przeglądarkę (wyłącznie podczas tworzenia witryny: po zakończeniu witryna jest widoczna jako HTML)
- brak negocjacji zawartości
- brak cloakingu
WADY:
- dodatkowa (niepotrzebna?) komplikacja
- komplikacja ta jest bardzo duża, gdy pracujemy w gołym HTML-em (bez PHP i innych server-side)
- staroświecki (?) (witrynę widać jako HTML)
Rozwiązanie 4
Język, nagłówek HTTP:XHTML 1.0 strict
Deklaracja DOCTYPE:XHTML 1.0 strict
wysyłany jako: warunkowo (negocjacja zawartości) text/html lub application/xhtml+xml
Deklaracja XML: warunkowo (cloaking, negocjacja zawartości)
Stosujemy drobny cloaking: podmieniamy nagłówek strony (chodzi głównie o usunięcie deklaracji XML). Ma to na celu wymuszenie trybu standardów w przeglądarce MSIE.
ZALETY:
- pełna zgodność ze standardami
- możliwość skorzystania z walidacji XHTML przez przeglądarkę
WADY:
- drobne problemy przy przygotowywaniu wersji offline (trzeba użyć software’u, który korzysta z negocjacji zawartości)
- wersja offline różna od online (wersja offline będzie w istocie rozwiązaniem niezgodnym ze standardami)
- cloaking: być może źle widziany przez wyszukiwarki?
- dodatkowa (niepotrzebna?) komplikacja (tj. negocjacja zawartości)
- wymaga technik server-side (np. PHP); nie da się osiągnąć w gołym HTML-u
Rozwiązanie 5
Język, nagłówek HTTP: język: XHTML 1.0 strict lub wyższy
Deklaracja DOCTYPE: XHTML wysyłany zawsze jako application/xhtml+xml
Deklaracja XML: zawsze obecna
brak negocjacji zawartości i cloakingu
ZALETY:
- nie wymaga technik server-side (np. PHP)
- pełna zgodność ze standardami
- możliwości skorzystania z walidacji XHTML przez przeglądarkę
- brak negocjacji zawartości
- brak cloakingu
- wersja offline identyczna (z dokładnością do nagłówka HTTP) z wersją online
WADY:
- nieobsługiwany przez MSIE
