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.
- Reklama -
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.
- Reklama -
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
