Strony internetowe w postaci takiej, jakimi znamy je dzisiaj zaczęły powstawać w 1991 roku. Przez 17 lat twórcy stron WWW używali HTML-a tak jak im było wygodnie. W końcu zaczyna się to zmieniać.
Trochę historii
Ponieważ nauka podstaw HTML-a nie jest trudna, a zrozumienie idei i najważniejszych znaczników zajmuje maksymalnie kilka godzin, właściwie każdy jest w stanie stworzyć i (niestety) opublikować własną witrynę w sieci. W początkowych fazach rozwoju języka (mniej więcej do połowy lat 90.) nie istniały jednolite standardy tworzenia stron, ani ich wyświetlania przez przeglądarki.
Z tego właśnie powodu webmasterzy zaczęli tworzyć strony przeznaczone tylko dla Internet Explorera lub Netscape Navigatora (Opera dopiero raczkowała, a Firefoksa jeszcze nie było) lub na konkretne rozdzielczości (część Czytelników może nie pamiętać komunikatów: \”wybierz rozdzielczość: 800×600, 1024×768\”). Trudno sobie wyobrazić taki wybór na każdej odwiedzanej stronie (a tym bardziej przystosowywanie witryn) dzisiaj, kiedy sieć przeglądana jest przez co najmniej 4 popularne przeglądarki, a witryna musi wyświetlać się na zwykłym monitorze, kilkudziesięciocalowym telewizorze podłączonym do media-center i na ekranie telefonu. Ale nastał rok 1997…
Uporządkujmy internet
Rok 1997 wiąże się z dwoma ważnymi dla webmasterów zdarzeniami: wprowadzeniem CSS (Cascading Style Sheets, kaskadowe arkusze stylów) oraz czwartej wersji języka HTML. Po sześciu latach dowolności w stosowaniu znaczników HTML-a ktoś wreszcie zwrócił uwagę na ujednolicenie – była to organizacja W3C. Główne zalety wprowadzenia HTML 4.0 (i późniejszych pochodnych) oraz arkuszy stylów to oddzielenie warstwy prezentacji od treści oraz ujednolicenie stosowanych znaczników. Mimo że takie podejście było prawdziwym przełomem, do dzisiaj nie udało się ujednolicić budowy stron WWW (a minęło już ponad 10 lat!). Gdzie leży wina? Po części po stronie programistów, którzy nie zawsze stosują się do standardów.
Nie zawsze nawet o nich wiedzą! Wiąże się to ze
wspomnianą łatwością przyswojenia podstaw języka
– większość początkujących programistów nie
widzi różnicy między znacznikiem {html}{/html} i {html}{/html}
– obydwa pogrubiają tekst i wyglądają tak samo…
Niestety, nie służą do tego samego, a wygląd można
samemu zdefiniować w arkuszu stylów.
Aby uzmysłowić sobie różnicę, warto przypomnieć
znaną wśród projektantów anegdotę. Wyobraźmy
sobie, że czytnik dla niewidomych przegląda
treść e-maila. Informacja \”Poznałem dwie
{html}{/html}dziewczyny{html}{/html}\” zostanie odczytana
z akcentem na słowo \”dziewczyny\”, natomiast
\”Poznałem dwie {html}{/html}dziewczyny{html}{/html}\” jako \”poznałem
dwie grube dziewczyny\”… Różnica jest znacząca,
zwłaszcza dla autora e-maila. Dobrze zastosowane
znaczniki pozwalają na logiczne opisanie
treści (co w przyszłości ułatwi powstanie sieci semantycznych)
– {html}{/html} stosuje się do wyróżnienia
zaznaczonej frazy, a nie pogrubienia.
Drugą grupą winną takiej sytuacji są producenci
oprogramowania. Wystarczy obejrzeć źródła
stron generowanych przez edytory takie jak Front-
Page, w których roi się od zbędnego kodu (w dodatku
niezgodnego ze standardami). Kolejną grupą
winnych są same przeglądarki i ich autorzy. Tu sytuacja
wyglądała tragicznie jeszcze niedawno, kiedy
większość internautów przeglądała sieć za pomocą
Internet Explorera 5.0 i 5.5 – rozbieżności między
stronami wyświetlanymi przez IE a inne przeglądarki
były olbrzymie. Wraz z pojawieniem się wersji 6 i 7
sytuacja powoli się poprawiła, ale i tak przeglądarki
Microsoftu znane są z niepoprawnego wyświetlania
stron i trudnych do poprawienia błędów.
Po szybkim przejrzeniu genezy HTML-a i CSS-a
widzimy, że wszystkie niezgodności w sieci, a co za
tym idzie olbrzymi bałagan wynikają z pracy programistów
– zarówno twórców przeglądarek, narzędzi
do tworzenia stron WWW, jak i mających
małe pojęcie o standardach webmasterów. Pora
nadrobić zaległości!
Pojęcia
HTML (HyperText Markup Language – hipertekstowy język znaczników) – język stosowany
od 1991 roku do opisu warstwy informacyjnej i prezentacji dokumentów przeznaczonych do
publikacji w sieci. Obecnie opis warstwy prezentacji przenoszony jest do arkuszy stylów.
XHTML (Extensible HyperText Markup Language – rozszerzalny hipertekstowy język znaczników)
– język znaczników podobny do HTML-a, ale zgodny ze specyfikacją XML-a, co pozwala
na łatwe generowanie dokumentów i lepsze \”zrozumienie\” zawartości przez programy.
CSS (Cascading Style Sheet – kaskadowe arkusze stylów) – zestaw poleceń i atrybutów
służący do opisu warstwy prezentacyjnej dokumentu HTML i pokrewnych.
W3C – World Wide Web Consortium. Organizacja zajmująca się ustanawianiem i propagowaniem
standardów dotyczących stron WWW, m.in.: HTML, XHTML, XML, CSS, DOM itp.
Acid2, Acid3 – testy przygotowane przez organizację Web Standards Project (http://www.webstandards.org), sprawdzające poprawność stron generowanych przez przeglądarki. W założeniu testy mają doprowadzić do zachowania standardów nałożonych przez W3C.
DOM (Document Object Model – Obiektowy Model Dokumentu) – sposób obiektowej reprezentacji
dokumentów. W3C zdefiniowało zestaw poleceń dających kontrolę nad tak opisanym
dokumentem, niezależnych od języka programowania.
WYSIWYG (What You See Is What You Get – To Co Widzisz Jest Tym Co Otrzymasz. Zwykle
tym mianem określa się programy dające jako końcowy efekt dokument taki, jakim widzimy
go podczas edycji. Przykładem jest choćby Word.
Walidator – program lub skrypt badający zgodność (w przypadku artykułu) strony WWW
z zatwierdzonym standardem. Jeden z najlepszych walidatorów znajduje się pod adresem
http://validator.w3.org.
Co jest nie tak?
Najważniejszą, rewolucyjną wręcz cechą wniesioną przez CSS jest oddzielenie warstwy prezentacji od treści. Ma to zasadniczy wpływ na czytelnika, gdyż internet jest głównie źródłem informacji, a wszystkie ozdobniki (kolorowy tekst, układ stron, rozwijane menu itp.) są tylko dodatkiem mającym w najlepszym przypadku ułatwić dostęp do treści.
Nie zawsze się to jednak udaje. Umieszczanie wewnątrz dokumentu z treścią elementów prezentacyjnych, np. znacznika {html}{/html} może dla niektórych być wygodne, jednak utrudnia pracę np. przeglądarkom dla niewidomych i zwiększa rozmiar strony, a co za tym idzie ilość przesyłanych danych. Osoba odwiedzająca stronę z komórki z GPRS-em boleśnie odczuje takie rozwiązanie, płacąc za transfer dodatkowe pieniądze. Ile można zaoszczędzić na przeniesieniu znaczników prezentacyjnych poza treść?
Kilka dni temu, podczas odświeżania witryny
pewnej firmy, trafiłem na zestaw tabel, w których
prawie każda komórka była opisana kilkoma
znacznikami, takimi jak wielkość tekstu czy szerokość.
Przeniesienie ich do arkusza stylów pozwoliło
zmniejszyć rozmiar tabeli dwunastokrotnie (o ponad
90%)! Różnica może więc być olbrzymia, choć zwykle
rozmiar witryny zmniejsza się o 30-50%.
Poza utrudnieniem życia niektórym czytelnikom
sami właściciele stron cierpią na ich złej budowie.
Każdego dnia internet jest przeszukiwany przez roboty
wyszukiwarek, które indeksują witryny. Każda
niezgodność z przyjętymi standardami zwiększa ryzyko zagubienia się robota w labiryncie znaczników
i zaprzestania indeksowania.
Przytoczone argumenty powinny być wystarczające,
żeby osoby poważnie traktujące swoje witryny
(w szczególności firmy zajmujące się ich projektowaniem)
zaczęły oddzielać warstwę prezentacji
od treści. Mimo że obecnie poprawne kodowanie
powinno być standardem – nie jest. Dlaczego?
Odpowiedź jest prosta. Podczas tworzenia witryny
łatwo dodać jednemu tagowi atrybuty prezentacyjne,
co prowadzi do natychmiastowego efektu
– witryna wygląda jak powinna, mimo że zawiera
wiele błędów. Natomiast prawdziwy koszmar czeka
osobę zajmującą się stroną, jeśli okaże się, że
trzeba wprowadzić modyfikacje lub odświeżyć jej
wygląd. Elementy prezentacyjne zawarte w treści
utrudnią (lub uniemożliwią) wprowadzenie poprawek,
co może doprowadzić nawet do konieczności
budowy strony od nowa i poniesienia kolejnych
kosztów. A wystarczyłoby zapoznać się ze specyfikacją
i wykonać dobry plan projektu.
JavaScript
JavaScript był wykorzystywany najpierw do wstawiania
na witryny dodatkowych elementów, jak
kalendarze, latające za kursorem zwierzątka, wyskakujące
okienka itp. Trzeba przyznać, że wtedy
bardziej przeszkadzał niż pomagał. Wprowadzenie
(w 2004 roku) przez W3C trzeciej wersji modelu
DOM (Document Object Model – obiektowy model
dokumentu) spowodowało zmianę.
JavaScript zaczął być wykorzystywany do ułatwiania dostępu do treści – poprawienia obsługi formularzy, dynamicznego generowania treści (popularny AJAX) bez przeładowywania strony itp. Mimo że JavaScript nadal jest nadużywany, wydaje się, że idzie w dobrym kierunku. Nadużycie polega na stosowaniu skryptów jako elementów koniecznych do wygenerowania strony. Konkretne przykłady to wywoływanie linków tylko przez skrypty, zmuszanie użytkownika do otwarcia nowego okna oraz wstawianie zbędnych skryptów w treść strony (przykład z życia: {html}{/html}). Tu znów zamykamy drogę wyszukiwarkom, użytkownikom mającym wyłączony JavaScript i takim, którym skrypty jeszcze się nie załadowały.
Nowoczesne przeglądarki zwykle najpierw ładują
treść strony (łącznie z obrazkami w {html}{/html}),
a dopiero po wczytaniu tych informacji zajmują
się dołączeniem arkusza stylów i uruchomieniem
skryptów (chociaż to częściowo zależy od metody
dołączenia JavaScriptu). Jest to działanie jak najbardziej
pozytywne i pożądane. Wystarczy jednak,
że na stronie opublikujemy plik wideo lub większe
zdjęcia i już czas potrzebny do załadowania treści
zwiększa się do kilkudziesięciu sekund. Znając tę
cechę działania przeglądarek łatwo zauważyć, że
często spotykamy się z sytuacją, kiedy to JavaScript
nie działa. Płynie z tego prosty wniosek: nie można
kluczowych elementów witryny powierzyć JavaScriptowi,
bo przez jakiś czas może go nie być.
Czas ten zależy od obciążenia serwera, łącza, przeglądarki
użytkownika itp. czynników, których nie
jesteśmy w stanie przewidzieć. Oczywiście można
temu zaradzić, ale wymaga to dokładnego zaznajomienia
się z działaniem JavaScriptu.
Czy to oznacza, że JavaScript jest zły? Wręcz
przeciwnie – dobrze zastosowany potrafi znacząco
ułatwić dostęp do informacji. Dzięki dynamicznemu
generowaniu treści strony nie musimy czekać
na przeładowanie witryny, sprawdzimy poprawność
formularzy przed wysłaniem, zmniejszymy ilość wysyłanych
danych i obciążenie serwera (poprzez wykonanie
części operacji po stronie klienta) itd. Ważne jest jednak zachowanie umiaru i ograniczenie
zaufania do skryptów – w żadnym wypadku nie
mogą być one podstawowym czynnikiem generującym
elementy strony oraz sprawdzającym poprawność
danych wysyłanych na serwer.
Przykładem dobrze zaprojektowanego serwisu
może być nowa odsłona portalu onet.pl. Treść
ładuje się natychmiast, później grafika w artykułach.
Natomiast skrypty z programem TV, pogodą
itp. ładują się, kiedy możemy już czytać wiadomości. Linki są poprawnie skonstruowane i przed
załadowaniem JavaScriptu przenoszą na wskazaną
stronę, a po nim pokazują szczegóły bez przeładowywania
całości witryny. Wyszukiwarka Zumi na
żywo podpowiada szukane frazy itd.
Walidatory
W przypadku stron tworzonych w języku XHTML
(Extensible HTML – rozszerzalny HTML) możemy
mówić o semantyce kodu, czyli takim opisie treści,
że jest ona \”zrozumiała\” dla komputera. W standardzie
XHTML przeglądarki i wyszukiwarki są
w stanie nie tylko znaleźć na stronie treść, ale wiedzą
również, czy znaleziony tekst jest nagłówkiem,
elementem listy czy może opisem formularza.
Niestety,
edytory WYSIWYG nie potrafią
wstawić odpowiednich tagów – dla człowieka
umieszczenie powiększonego tekstu na górze dokumentu
jest oczywistym tytułem, ale dla maszyny
nie. Mimo że profesjonalne edytory WYSIWYG
(np. Dreamweaver) mogą wygenerować poprawny
kod, nie uda im się stworzyć w pełni semantycznego
dokumentu. Jak więc wygenerować poprawną
witrynę?
Trzeba tworzyć szkielet ręcznie, a z programów
wspomagających korzystać w dalszej części
pracy. Ręczne kodowanie ma dodatkową zaletę
w postaci maksymalnie optymalizowanego kodu –
tu również nic nie jest w stanie zastąpić doświadczonego
programisty. W przeciwieństwie do wygenerowania
przez program poprawnego dokumentu
sprawdzenie czy semantyka (w przypadku starszych
standardów – składnia) została zachowana nie jest
trudne. Doskonałym narzędziem sprawdzającym poprawność
kodu są udostępniane przez W3C walidatory.
Skrypt taki potrafi przetestować poprawność
strony, wskazać napotkane błędy (wraz z sugestiami
co do przyczyny) i potwierdzić zgodność
ze standardem – wynik działania skryptu widać na
rys. 7. Oczywiście jest to tylko skrypt, więc badany
jest jedynie model dokumentu i poprawność składni
– walidator nie potrafi stwierdzić, czy treść znajdująca
się w {html}
{/html} jest tytułem czy przypadkowym
ciągiem liter. Mimo to zatwierdzona przez
walidator strona powinna prezentować się dobrze
na większości urządzeń.
Testowanie kwasem
|
|
|
|
Kolejnym testem badającym zgodność ze standardami
jest Acid (kwas) – tym razem sprawdzana jest
zgodność przeglądarek ze standardem. Test (w aktualnej
wersji zestaw testów) polega na wyświetleniu
specjalnie przygotowanej witryny zawierającej
instrukcje szczególnie narażone na błędne wyświetlanie
(przezroczystość, atrybuty CSS, dynamicznie
generowana treść oraz obsługa DOM).
W tej chwili większość przeglądarek przechodzi drugą wersję testu,
ale trzecia wersja jest zaliczana w pełni jedynie
przez Safari – patrz rys. 1-6. Użytkownicy czy webmasterzy
nie mają wpływu na wynik testu (mogą
jedynie zgłaszać propozycje testów cząstkowych)
– tu wszystko zależy od programistów tworzących
przeglądarki. Paradoksem wydawać się może, że
strona z testem Acid3 nie jest zgodna ze standardami (niepoprawny CSS). Jest to jednak zamierzone
działanie. Ma ono zmusić przeglądarki do ignorowania
niepoprawnej składni. Niewątpliwie wszyscy
na tym zyskają – żeby strona wyświetlała się tak,
jak początkujący koder sobie życzy, będzie musiał
od początku uczyć się poprawnej składni.
|
|
|
|
Być może dzięki temu zmniejszy się liczba stron niezgodnych
ze standardami i straszących swoim kodem.
Oczywiście standardy nie zawsze są idealne
i powinny ewoluować, przystosowując się do realiów
internetu. Taka sytuacja ma miejsce
na przykład w testach Acid – trzecia
wersja testuje głównie dynamiczne
generowanie treści, czego Acid2 prawie
wcale nie uwzględniał. Trzeba przyznać, że zestaw
testów przewidzianych przez Acid3 jest bardzo
wymagający, ale producenci Opery, Firefoksa
i Safari starają się jak mogą, żeby najnowsze wersje
ich programów wyświetlały strony poprawnie. Niestety,
nie można powiedzieć tego o Internet Explorerze
– nawet IE8 zdobywa tylko kilkanaście procent
punktów.
Nie można pominąć jeszcze jednego faktu –
wydawałoby się, że witryna tak prosta i znana jak
Google powinna się walidować i być wzorowo napisana.
Nic z tych rzeczy – strona startowa google.com ma ponad 60 błędów (!). Ich poprawa nie jest
trudna, ale Google ma dobrze działać wszędzie, nawet
na przeglądarkach, które powstały przed testami
Acid i specyfikacją W3C. Wspomniane błędy
to tak naprawdę tzw. \”hacki\”, czyli instrukcje mające
dostosować wygląd witryny w jednej z przeglądarek
źle interpretującej kod. Z tego prostego
powodu firma może sobie pozwolić na niezgodność
ze standardami na rzecz poprawnego wyświetlania
w starszych przeglądarkach.
Przyszłość
W przyszłości możemy spodziewać się dalszego
zwiększenia zainteresowania zgodnością ze standardami
(mam nadzieję, że ten artykuł kogoś przekona).
Niewątpliwie programiści przystosują przeglądarki
do prawidłowego wyświetlania stron, co
wymusi poprawne tworzenie witryn. Trudno natomiast
ocenić, jak będzie wyświetlał się niepoprawny,
niezgodny ze standardem kod – najlepiej
byłoby, gdyby był przez przeglądarki ignorowany,
jednak wydaje się to niemożliwe ze względu na
olbrzymią liczbę dokumentów dostępnych w sieci.
W ciągu kilku lat prawdopodobnie rozwinie się
\”inteligencja\” przeglądarek i wyszukiwarek, a co za
tym idzie będzie można w pełni wykorzystać semantykę
XHTML-a i jego następców.
Zalety zachowania standardów
- witryna dostępna dla większej liczby czytelników
- krótki kod
- łatwe wprowadzanie zmian
- lepsze indeksowanie przez Google
- dostęp do treści przed załadowaniem dodatków
- oddzielenie warstw prezentacji, treści
i zachowania (skrypty)
