Rozdział 2. Jak tu dotarliśmy, czyli zwięzła historia HTML-a

> Dodaj do ulubionych

Do rzeczy

Niedawno natknąłem się na słowa programisty z Mozilli dotyczące problemów tworzenia standardów:

Implementacje i specyfikacje muszą odpowiednio ze sobą współpracować. Nie chcesz, aby implementacja została utworzona przed ukończeniem specyfikacji, ponieważ ludzie zaczną polegać na szczegółach implementacji, a to powoduje ograniczanie specyfikacji. Jednak nie chcesz też, aby specyfikacja została ukończona przed zakończeniem implementacji oraz zanim ktoś z nich zacznie korzystać, ponieważ potrzebne są komentarze. Występuje tutaj zatem nieunikniony konflikt, ale musimy sobie z tym jakoś radzić.

Zapamiętaj ten cytat i przeczytaj resztę tekstu w tym rozdziale, aby dowiedzieć się dlaczego powstał język HTML5.

Typy MIME

Jest to książka o języku HTML5, a nie poprzednich wersjach HTML-a, ani jakiekolwiek wersji HTML5 należy najpierw zrozumieć kilka technicznych zagadnień, a zwłaszcza typy MIME.

Za każdym razem gdy przeglądarką wysyła zapytanie o stronę, serwer sieciowy przed wysłaniem rzeczywistego kodu HTML, najpierw wysyła tzw. nagłówki. Normalnie nagłówki te są niewidoczne, jednak istnieją narzędzia umożliwiające ich przeglądanie. Nagłówki są ważne, ponieważ informują przeglądarkę, w jaki sposób interpretować dany kod znacznikowy. Najważniejszym nagłówkiem jest Content-Type, który wygląda następująco:

Content-Type: text/html

Fragment text/html nazywa się typem treści lub typem MIME strony. Ten nagłówek jest jedyną rzeczą, która określa rodzaj danych i w jaki sposób powinny one być interpretowane. Obrazy mają własne typy MIME (np. format JPEG ma typ MIME image/jpeg, format PNGimage/png itd.). Pliki JavaScript maja swoje własny typ MIME. Kaskadowe arkusze stylów (CSS) też mają swój typ MIME. Wszystko ma swój typ MIME. Cały internet opiera się na typach MIME.

Oczywiście rzeczywistość jest bardziej skomplikowana. Pierwsza generacja serwerów (mówię tu o serwerach z 1993 r.) nie wysyłały nagłówków Content-Type, ponieważ jeszcze wtedy nie istniały (powstały w roku 1994). Ze względu na kwestie zgodności oprogramowania, niektóre przeglądarki ignorują nagłówek Content-Type w pewnych warunkach. Jest to tzw. „wykrywanie treści” — ang. content sniffing. Jednak podstawową zasadą jest to, że wszystko co kiedykolwiek widziałeś w sieci — strony HTML, obrazki, skrypty, filmy, pliki PDF oraz wszystko co ma jakiś adres URL — zostało do Ciebie wysłane z serwera za pomocą typów MIME określonych w nagłówku Content Type.

Pamiętaj o tym. Jeszcze do tego wrócimy.

Długa dygresja na temat tworzenia standardów

Niecodziennie słyszy się pytanie skąd wziął się element img. Oczywiście ktoś musiał go wymyślić. Takie rzeczy nie pojawiają się znikąd. Każdy element, każdy atrybut języka HTML, którego kiedykolwiek używałeś ktoś wymyślił i zdecydował w jaki sposób powinny te rzeczy działać, a następnie to zapisał. Ci ludzie nie są ani bogami ani nieomylni.

Jedną z największych zalet prac nad standardami w sposób otwarty jest to, że zawsze możesz się cofnąć w czasie i odpowiedzieć na tego rodzaju pytania.

W dniu 25 lutego 1993 r. Marc Andreessen napisał:

Chciałbym zaproponować nowy znacznik języka HTML:

IMG

Wymagany argument to SRC="url".

Za jego pomocą podawałoby się nazwę bitmapy lub pixmapy, którą przeglądarka pobierałaby poprzez sieć, interpretowała jako obraz i osadzała w tekście w miejscu wystąpienia znacznika.

Oto przykład:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

(Nie ma tutaj znacznika zamykającego; jest to znacznik samodzielny).

Znacznik ten może być osadzony jak wszystko inne. Kiedy tak się stanie, będzie on ikoną, którą można aktywować, jak zwykły zakotwiczony tekst.

Twórcy przeglądarek powinni sami decydować, które formaty obrazów będą obsługiwać ich programy, mogą to być np. Xbm i Xpm. Jeśli przeglądarka nie może zinterpretować danego formatu, może zrobić cokolwiek (na przykład przeglądarka Mosaic dla użytkowników X Window System wyświetli domyślną bitmapę, jako tekst symbol zastępczy).

Tak aktualnie działa przeglądarka Mosaic dla X Window System i planujemy jej używać przynajmniej wewnętrznie. Jestem otwarty na propozycje, jak to powinno być rozwiązane w języku HTML; jeśli masz lepszą propozycję od tej, która została tu zaprezentowana, daj mi znać. Wiem, że jest problem z formatem obrazów, ale nie widzę żadnej alternatywy, jak tylko pozwolić przeglądarce zrobić, co może i poczekać na pojawienie się lepszego rozwiązania (typ MIME, pewnego dnia, może).

Xbm oraz Xpm były popularnymi formatami graficznymi pod system Linux.

Jedna z pierwszych na świecie przeglądarek nazywała się Mosaic (Wersja X Mosaic działała pod systemem Unix). Kiedy Marc Andreessen pisał to w 1993, nie był jeszcze założycielem firmy Mosaic Communications Corporation, która uczyniła go sławnym, ani nie rozpoczął jeszcze nawet pracy nad swoim sztandarowym produktem Mosaic Netscape (być może bardziej znane Ci są późniejsze nazwy Netscape Corporation i Netscape Navigator).

Słowa „Typ MIME, kiedyś, może” odnoszą się do negocjacji treści, funkcji protokołu HTML polegającej na tym, że klient (np. przeglądarka internetowa) informuje serwer (np. serwer sieciowy) jakie typy zasobów obsługuje (np. image/jpeg), tak aby serwer mógł wysłać coś w preferowanym formacie. Wstępne wersje protokołu HTTP z 1991 r. (jedyna wersja, która została zaimplementowana w lutym 1993 r.) nie umożliwiały klientom informowania serwera, jakie rodzaje obrazów obsługują, dlatego Mark stanął przed tym dylematem.

Kilka godzin później odpowiedział Tony Johnson:

Mam coś bardzo podobnego w aplikacji Midas 2.0 (używanej przez nas w SLAC i mającej się pojawić publicznie w najbliższych tygodniach), chociaż zastosowaliśmy inne nazwy i dodatkowy argument NAME="name". Nasza propozycja ma prawie taką samą funkcjonalność jak Twój znacznik IMG, np.:

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

Parametr name miał umożliwić przeglądarce posiadanie wielu „wbudowanych obrazków”. Jeżeli zostałaby wpisana nazwa „wbudowanego” obrazka, to mógłby zostać użyty ten obraz zamiast pobierania obrazu z zewnątrz. Nazwa ta mogłaby być też wskazówką dla przeglądarek tekstowych, jakiego symbolu użyć w miejsce obrazka.

Nie przywiązuję większej wagi do nazw parametrów czy znaczników, ale byłoby rozsądne gdybyśmy używali tych samych. Tak samo nie przywiązuję większej wagi do skrótów, np.: dlaczego nie IMAGE= czy też SOURCE=. Czasami wolę ICON, ponieważ nazwa podpowiada, że IMAGE powinien być mniejszy, ale być może nazwa ICON jest zbyt mocnym słowem?

Inną z wczesnych przeglądarek była przeglądarka Midas, rówieśniczka X Mosaic. Była to tzw. przeglądarka międzyplatformowa. Działała zarówno na platformie Unix jak i VMS. Akronim SLAC odnosi się do Centrum Liniowego Akceleratora Stanforda i obecnie funkcjonuje pod nazwą SLAC National Accelerator Laboratory, które miało pierwszy serwer sieciowy w Stanach Zjednoczonych (prawdę mówiąc pierwszy poza granicami Europy). Kiedy Tony pisał tę wiadomość, SLAC był weteranem stron WWW, przechowując pięć stron na swoim serwerze przez ogromną liczbę 441 dni.

Tony pisał dalej:

Skoro już mowa o nowych znacznikach, mam jeszcze jeden, który chciałbym aby był obsługiwany przez przeglądarkę Midas 2.0. Chodzi mi o:

<INCLUDE HREF="...">

Jego działanie polegałoby na tym, że powodowałby wstawienie wskazanego dokumentu w miejscu występowania tego znacznika. Dokument ten mógłby być czymkolwiek, ale główny cel to umożliwienie osadzania obrazków (o niegraniczonych rozmiarach w tym przypadku) w dokumentach. Ogólnie chodzi o to, że kiedy pojawi się protokół HTTP2, format dołączanego dokumentu podlegałby osobnej negocjacji.

Nazwa HTTP2 odnosi się do podstawowego protokołu HTTP zdefiniowanego w 1992 r. W tym czasie, na początku 1993 r., protokół ten wciąż nie był zaimplementowany. W końcu protokół znany pod nazwą HTTP2 rozwinął się i powstał standard znany jako: HTTP 1.0 (chociaż dopiero za trzy lata). HTTP 1.0 zawierał nagłówki dla negocjacji treści, znane jako „typ MIME, kiedyś, może”.

Tony kontynuował:

Inną alternatywą, którą rozważałem jest:

<A HREF="..." INCLUDE>Zobacz zdjęcie </A>

Nie bardzo podoba mi się dalsze rozszerzanie funkcjonalności znacznika <A>, ale chodzi mi o to, aby utrzymać zgodność z przeglądarkami, które nie honorują parametru INCLUDE. Zamierzeniem jest, aby przeglądarki, które obsługują znacznik INCLUDE zastąpiły zakotwiczony tekst (Zobacz zdjęcie) załączonym dokumentem (obrazkiem), podczas gdy mniej inteligentne lub starsze przeglądarki całkowicie go ignorowały.

Propozycja ta nigdy nie została wdrożona, chociaż pomysł z obsługą tekstu w przypadku brakującego obrazka jest wciąż ważną techniką dostępności, której brakowało Marcowi jeśli chodzi o znacznik IMG. Kilka lat później element ten został wprowadzony jako atrybut <img alt>, który programiści z Netscape od razu zepsuli przez błędne traktowanie go jako chmurki.

Kilka godzin po wiadomości od Tonyego, nadeszła odpowiedź od Tima Bernersa-Lee:

Wyobrażałem sobie, że obrazki będą wyglądały następująco:

<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Obrazek </a>

gdzie poszczególne parametry mają następujące znaczenie

EMBED	       Osadź to tutaj 
PRESENT	 Przedstaw to zawsze, gdy prezentowany jest dokument źródłowy

Można stosować różne kombinacje i jeśli przeglądarka czegoś nie obsługuje, to nic się nie stanie.

Rozumiem, że używanie tego, jako metody tworzenia wybieralnych ikon oznacza zagnieżdżanie kotwic. Hmmm, ale nie chciałem specjalnego znacznika.

Propozycja ta nigdy nie została wdrożona, ale atrybut rel jest wciąż używany.

Jim Davis dodał:

Byłoby milo, gdyby istniał sposób na sprecyzowanie typu treści, tzn.

<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>

Jednak bez problemu mogę pogodzić się z koniecznością określania typu treści poprzez rozszerzenie pliku.

Ta propozycja również się nie przyjęła, jednak Netscape dodał później obsługę osadzenia obiektów medialnych za pomocą elementu <embed>.

Pytanie Jaya C. Webera:

Podczas gdy obrazki są na szczycie mojej listy żądań typów mediów w przeglądarkach WWW, nie sądzę, abyśmy potrzebowali dodawania specyficznych elementów dla pojedynczych mediów. Co się stało z entuzjastami mechanizmu MIME?

Riposta Marca Andreessena:

Nie ma to na celu zastąpienia mającego się nastąpić używania typów MIME jako standardowego mechanizmu; umożliwia to wprowadzenie ważnej i prostej implementacji funkcjonalności, która jest potrzebna niezależnie od typów MIME.

Odpowiedź Jay C. Webera

Zapomnijmy chwilowo o typach MIME, jeśli zamazują ogólny obraz. Moje zastrzeżenie dotyczyło dyskusji „w jaki sposób obsługiwać osadzone obrazy”, a nie tego „w jaki sposób obsługiwać osadzone obiekty w różnych mediach”.

W przeciwnym razie za tydzień ktoś inny podrzuci propozycję, aby utworzyć nowy znacznik <AUD SRC=”file://foobar.com/foo/bar/blargh.snd”> dla treści dźwiękowych.

Nie powinno być trudne opracowanie jakiegoś bardziej ogólnego rozwiązania.

Po fakcie okazuje się, że obawy Jaya były słuszne. Wprawdzie zajęło to znacznie więcej niż tydzień, ale w końcu w języku HTML5 wprowadzono nowe elementy video i audio.

Odpowiedź Dave’a Raggeta na początkową wiadomość Jaya:

Racja! Chcę rozważyć wszelkie możliwości dotyczące typów grafiki wraz z możliwościami negocjacji treści. Uwaga Tima dotycząca obszarów reagujących na kliknięcie wewnątrz obrazów jest również ważna.

Następnie w 1993 Dave Ragget zaproponował HTML+ jako rozwinięcie standardu HTML. Jego propozycja jednak nigdy się nie przyjęła i została wyparta przez HTML 2.0. HTML 2.0 był specyfikacją zgodną z wcześniejszą wersją, co oznacza, że ostatecznie sformalizowano w nim to, co było już w powszechnym użyciu. „Niniejsza specyfikacja spaja, wyjaśnia i nadaje ostateczny kształt zestawom elementów, które w przybliżeniu pokrywają się z możliwościami HTML w powszechnym użyciu przed czerwcem 1994 r.”

Później, w oparciu o swój wcześniejszy szkic HTML+, Dave napisał HTML 3.0. Specyfikacja ta została jednak zaimplementowana wyłącznie przez W3C, jako implementacja referencyjna o nazwie Arena. Projekt ten został później wyparty przez HTML 3.2, kolejną „specyfikację zgodną z wcześniejszą wersją”: „W HTML 3.2 dodano powszechnie wykorzystywane elementy takie jak tabele, aplety oraz możliwość otaczania obrazów tekstem, jednocześnie zachowując pełną zgodność ze standardem HTML 2.0”.

Dave został później współautorem HTML 4.0, pracował nad programem HTML Tidy i brał udział w pracach nad XML, XForms, MathML i innymi nowoczesnymi specyfikacjami W3C.

Wracając do 1993 roku, oto odpowiedź Marca do Dave’a:

Właściwie może powinniśmy pomyśleć o proceduralnym języku do tworzenia grafiki, za pomocą którego moglibyśmy osadzać dowolne hiperłącza powiązane z ikonami, obrazami, tekstem lub w czymkolwiek innym. Czy ktoś jeszcze spotkał się z podobną funkcjonalnością w Intermedia?

Intermedia to nazwa projektu dotyczącego hipertekstu prowadzonego w Brown University. Był rozwijany od 1985 do 1991 r. i działał w systemie A/UX dla wczesnych komputerów Macintosh, podobnym do Uniksa.

Pomysł „języka programowania proceduralnego do tworzenia grafiki” w końcu się przyjął. Nowoczesne przeglądarki obsługują zarówno format grafiki SVG (znaczniki deklaratywne z obsługą języka skryptowego) oraz znacznik canvas (proceduralne bezpośrednie API graficzne), chociaż ten drugi początkowo był niestandardowym rozszerzeniem, zanim został wcielony do specyfikacji WHATWG.

Odpowiedź Billa Janssena:

Innymi godnymi uwagi systemami, w których można coś takiego znaleźć są Andrew i Slate. Andrew zawiera ramki (_insets_), z których każda ma określony typ, np. tekst, bitmapa, grafika, animacja, wiadomość, arkusz kalkulacyjny itp. Możliwe jest dowolne rekursywne zagnieżdżanie. Np. ramka może być osadzona w dowolnym miejscu w tekście widżetu tekstowego, lub w prostokątnym obszarze w widżecie rysowania lub dowolnej komórce arkusza kalkulacyjnego.

Nazwa Andrew odnosi się do Andrew User Interface System (chociaż w tamtym czasie był znany po prostu pod nazwą Andrew Project).

Tymczasem Thomas Fine miał inny pomysł:

Oto moja opinia. Najlepszym sposobem obsługi obrazów na stronach WWW jest używanie typów MIME. Jestem pewien, że postscript jest już obsługiwanym podtypem w MIME i całkiem dobrze sobie radzi łącząc grafikę z tekstem.

Pewnie powiecie, że to nie jest klikalne. Tak, macie rację. Podejrzewam, że jest już na to gotowa rada w Display Postscripcie. A nawet jeśli nie ma, to zaradzenie temu problemowi będzie bardzo łatwe. Wystarczy zdefiniować instrukcję kotwicy, która będzie określała adres URL i używała bieżącej ścieżki jako zamkniętego pola dla przycisku. Ponieważ postscript radzi sobie tak dobrze ze ścieżkami, tworzenie przycisków o dowolnych kształtach będzie banalnie proste.

Display Postricpt był technologią generowania obiektów na ekranie, rozwijaną przez Adobe i NeXT.

Propozycja ta nigdy nie została wdrożona, ale był, że najlepszym sposobem na naprawienie HTML-a jest zastąpienie go czymś innym ciągle pojawia się od czasu do czasu.

Tim Berners-Lee, 2 marca 1993 r.:

Protokół HTTP2 pozwala, aby dokument zawierał dane dowolnego typu, które użytkownik stwierdził, że może obsługiwać, a nie tylko zarejestrowane typy MIME. Można przeprowadzić eksperyment. Tak, sądzę, że jest miejsce dla postscriptu w hipertekście. Nie wiem tylko czy Display Postscript ma wszystko, co potrzebne. Wiem, że Adobe pracuje nad własnym formatem PDF opartym na postscripcie, który będzie mógł zawierać odnośniki i będzie odczytywany przez specjalne przeglądarki.

Sądziłem, że ogólny język dla kotwic (oparty na Hytime?) umożliwiłby hipertekstowi oraz standardom graficznym/video rozwijać się osobno, co byłoby pomocne dla obydwu stron.

Niech znacznik IMG zostanie zamieniony na INCLUDE i niech odnosi się do dowolnego typu dokumentu. Albo może też być nazwa EMBED jeżeli INCLUDE za bardzo kojarzy się z językiem C++ i kodem SGML parsowanym wewnątrzliniowo.

HyTime był wczesnym systemem dokumentów hipertekstowych opartym na SGML-u. Dominował on kiedyś dyskusje na temat HTML-a, a później XML-a.

Propozycja Tima dotycząca znacznika INCLUDE nigdy się nie przyjęła, ale można znaleźć jej echa w elementach object, embed i iframe.

W końcu 12 marca 1993 Marc Andresseen ponownie powrócił do wątku:

Wracając do wątku o obrazach śródliniowych — jestem coraz bliżej wydania przeglądarki Mosaic v0.10, która zgodnie z zapowiedziami będzie obsługiwała sródliniowe obrazy GIF i XBM.

W tym momencie nie jesteśmy jeszcze gotowi na obsługę znaczników INCLUDE/EMBED. …Zatem prawdopodobnie będziemy się skłaniać ku <IMG SRC="url"> (a nie ICON, ponieważ nie wszystkie obrazy śródliniowe można tak naprawdę nazwać ikonami). Na razie obrazy sródliniowe nie będą mieć bezpośrednio określanego typu treści, ale w przyszłości planujemy to zmienić (gdy technika MIME zostanie ogólnie przyjęta). Algorytmy odczytujące obrazy, których obecnie używamy określają format plików na bieżąco, a więc nawet rozszerzenie nie będzie potrzebne.

Ciągłość zachowana

Jestem niezwykle poruszony tą konwersacją sprzed prawie 17 lat, która doprowadziła do powstania elementu HTML dziś używanego praktycznie na każdej stronie internetowej. Ustalmy pewne fakty:

  • Protokół HTTP wciąż istnieje i z powodzeniem był ulepszany od wersji 0.9 do 1.0 i późniejszej 1.1. I wciąż jest doskonalony.
  • HTML wciąż istnieje. Ten prosty format danych — kiedyś nie obsługiwał nawet obrazów śródliniowych! — udanie ewoluował kolejno do wersji 2.0, 3.2 i 4.0. Ewolucja HTML-a jest ciągła. Wprawdzie miała swoje zakręty i perturbacje oraz zabrnęła kilka razy w ślepy zaułek, gdy czasami osoby opracowujące standardy wyprzedzali samych siebie (i oczywiście autorów oraz implementacje). Ale jednak, jest rok 2013 i strony z 1990 roku wciąż można wyświetlić w nowoczesnych przeglądarkach. Właśnie załadowałem jedną z nich w moim supernowoczesnym telefonie komórkowym z Androidem i nawet nie wyświetlił się komunikat „proszę czekać, trwa importowanie starego formatu”
  • HTML był zawsze tematem dyskusji pomiędzy twórcami przeglądarek, autorami, osobami zajmującymi się standardami oraz innymi osobami lubiącymi rozmawiać na temat tego, co się znajduje między ostrymi nawiasami. Najbardziej udanymi wersjami HTML-a były „specyfikacje zgodne z wcześniejszą wersją”, doganiające świat, równocześnie próbując delikatnie skierować go na właściwe tory. Każdy, kto mówi, że HTML powinien być „czysty” (przypuszczalnie ignorując, twórców przeglądarek lub autorów, ewentualnie obie te grupy), jest po prostu niedoinformowany. HTML nigdy nie był czysty, a wszelkie próby uczynienia go czystym okazały się spektakularnymi porażkami, z którymi można porównać tylko niepowodzenia zastąpienia go czymś innym.
  • Żadna z przeglądarek z 1993 nie istnieje już w rozpoznawalnej formie. Netscape Navigator został porzucony w 1998 r. i napisany od podstaw w ramach pakietu Mozilli, z którego później powstał Firefox. Skromne początki Internet Explorera sięgają aplikacji Microsoft Plus! dla systemu Windows 95, w którym był dołączony do motywów pulpitu i gry we flipera. Ale oczywiście tamta przeglądarka również ma swoją historię, którą można zbadać.
  • Niektóre z systemów powstałych w 1993 r. wciąż istnieją w jakiejś formie, jednak żaden z nich nie nadaje się do obsługi dzisiejszych stron internetowych. Większość ludzi obecnie przegląda internetu korzystając z systemu Windows 7 lub 8, Mac OS X, jakiegoś Linuksa albo podręcznych urządzeń typu iPhone. W 1993 r. Windows był w wersji 3.1 (i konkurował z OS/2). Komputery Macintosh działały pod kontrolą systemu System 7, a Linux był rozpowszechniany za pomocą Usenetu. (Chcesz się dobrze zabawić? Znajdź jakiegoś staruszka i szepnij mu „Trumpet Winsock” albo „MacPPP”).
  • Niektóre osoby wciąż są w branży i angażują się w prace nad kolejnymi standardami sieciowymi. Trwa to już ponad 20 lat. A niektórzy z nich działali nawet w czasach, kiedy jeszcze nie była HTML-a, w latach 1980 i wcześniej.
  • Skoro mowa o przodkach, przy ogromnej popularności, jaką zdobył HTML łatwo jest zapomnieć o innych formatach i systemach, które miały wkład w jego powstanie. Andrew? Intermedia? HyTime? HyTime np. nie był tylko jakimś szalonym projektem akademickim, to był standard ISO. Został zaakceptowany do celów wojskowych. To był coś poważnego. Można o nim poczytać na tej stronie HTML w przeglądarce internetowej.

Jednak wciąż nie znamy odpowiedzi na pytanie, dlaczego mamy element img? Dlaczego nie icon albo include? Dlaczego nie jest to łącze z atrybutem include albo kombinacja wartości rel? Dlaczego właśnie element img? Odpowiedź jest prosta. Ponieważ Marc Andreessen go zaimplementował, a zaimplementowane elementy wygrywają.

To nie znaczy, że każdy kod, który zostanie zaimplementowany na pewno wejdzie do powszechnego użytku. W końcu Andrew, Intermedia i HyTime również miały implementacje. Kod jest ważny, ale nie wystarcza do odniesienia sukcesu. A już na pewno nie twierdzę, że powstanie implementacji przed standardem jest gwarancją osiągnięcia idealnego rozwiązania. Element img Marca nie wprowadzał wspólnego formatu graficznego, nie definiował w jaki sposób ma on być otaczany tekstem ani też nie obsługiwał alternatywnego tekstu czy treści awaryjnej dla starszych przeglądarek. 19 lat później nadal zmagamy się z „wykrywaniem treści”, które wciąż stanowi źródło koszmarnych problemów z bezpieczeństwem. Całą historię tego elementu można prześledzić 19 lat wstecz, przez wielkie wojny przeglądarek, aż do 25 lutego 1993 r., dnia w którym Marc Andreessen rzucił od niechcenia „MIME, może kiedyś”, a mimo to opracował implementację.

Wygrywają ci, którzy implementują.

Historia HTML-a w latach 1997-2004

W grudniu 1997 r. Światowe Konsorcjum W3C opublikowało HTML 4.0 i jednocześnie rozwiązało grupę roboczą ds. HTML. Niecałe dwa miesiące później inna grupa robocza W3C opublikowała język XML 1.0. Zaledwie trzy miesiące po tym wydarzeniu ludzie z W3C zorganizowali warsztaty na temat Przyszłość języka HTML, aby udzielić odpowiedzi na pytanie „Czy W3C zrezygnowało z HTML-a?” Oto ich odpowiedź:

W toku rozmów zgodzono się, że dalsze rozwijane języka HTML 4.0, jak również przekształcenie go w aplikację XML byłoby trudne. Zaproponowano rozwiązanie polegające na rozpoczęciu prac nad nową generacją HTML-a opartą na „zestawach elementów XML”.

Konsorcjum reaktywowało grupę roboczą ds. HTML-a , której zadaniem było opracowanie tego „zestawu elementów XML”. Pierwszy krok nastąpił w grudniu 1998 r., kiedy opublikowano szkic tymczasowej specyfikacji, która po prostu przeformułowała HTML na XML bez dodawania jakichkolwiek nowych elementów czy też atrybutów. Specyfikacja ta stała się później znana pod nazwą XHTML 1.0. Zdefiniowano w niej nowy typ MIME dla dokumentów XHTML: application/xhtml+xml. Jednak w celu ułatwienia migracji istniejących stron napisanych w HTML 4.0 dołączono do niej dodatek C zawierający „wytyczne dla autorów chcących, aby ich dokumenty zakodowane w XHTML działały również w istniejących aplikacjach klienckich HTML”. W dodatku C zezwolono na serwowanie stron XHTML z typem MIME text/html.

Następnym celem W3C były formularze internetowe. W sierpniu 1999 r. ta sama grupa robocza opublikowała pierwszy szkic specyfikacji XHTML Extended Forms. Swoje oczekiwania przedstawili w pierwszym akapicie:

Po dokładnej analizie sytuacji grupa robocza ds. HTML-a zdecydowała, że cele związane z przyszłymi formularzami nie będą uwzględniać zgodności z przeglądarkami zaprojektowanymi dla wcześniejszych wersji HTML-a. Naszym celem jest opracowanie nowego klarownego modelu formularzy (XHTML Extended Forms) w oparciu o zestaw jasno zdefiniowanych wymagań. Wymagania opisane w niniejszym dokumencie zostały opracowane na podstawie danych zgromadzonych podczas korzystania z wielu aplikacji formularzowych.

Kilka miesięcy później nazwa HTML Extended Forms został zmieniona na XForms i prace przeniesiono do specjalnej grupy roboczej. Grupa ta pracowała równolegle z grupą roboczą ds. HTML-a i efektem jej prac była pierwsza edycja formularzy XForms 1.0 opublikowana październiku 2003 r.

Tymczasem głównym celem grupy ds. HTML-a po dokonaniu pełnej transformacji na XML było stworzenie „następnej generacji HTML-a”. W maju 2001 r. grupa opublikowała pierwszą edycję XHTML 1.1 w której dodano tylko kilka elementów, ale usunięto lukę w specyfikacji XHTML 1.0 dotyczącą dodatku C. W XHTML 1.1 dokumenty mogą być serwowane wyłącznie z typem MIME application/xhtml+xml.

Wszystko co wiesz o XHTML-u jest nieprawdą

Dlaczego typy MIME są tak ważne? Dlaczego ciągle do nich wracam? Trzy słowa: drakońska obsługa błędów. Przeglądarki zawsze pobłażliwie traktowały dokumenty HTML. Jeżeli utworzysz stronę HTML i zapomnisz znacznika </head>, przeglądarki i tak wyświetlą tę stronę (niektóre znaczniki niejawnie implikują koniec elementu head oraz początek body). Znaczniki należy zagnieżdżać hierarchicznie — tzn. ostatnio otwarty element powinien zostać zamknięty jako pierwszy — ale jeśli napiszesz taki kod: <b><i></b></i>, to przeglądarki też jakoś sobie z nim poradzą i nie wyświetlą żadnego powiadomienia o błędzie.

Jak można było się spodziewać, brak reakcji ze strony przeglądarek na błędy w kodzie spowodował, że autorzy tworzyli niepoprawnie skonstruowane strony w ogromnych ilościach. Według niektórych szacunków 99% dzisiejszych stron zawiera przynajmniej jeden błąd, a ponieważ błędy te nie są wyświetlane w oknach przeglądarek nikt ich nie naprawia.

Konsorcjum W3C uznało to za fundamentalny problem i przystąpiło do jego naprawy. Opublikowany w 1997 r. język XML zerwał z tradycją pobłażliwości dla twórców dokumentów. Każdy program interpretujący XML wszystkie błędy składniowe musi traktować jako krytyczne. Z czasem wymóg ten zaczęto nazywać „drakońską obsługą błędów”, od greckiego przywódcy o imieniu Draco, który stosował karę śmierci za nawet drobne naruszenia prawa. Kiedy W3C przeformułowało język HTML na słownik XML, sofrmułowano dodatkowo wymóg, aby wszystkie dokumenty serwowane jako MIME application/xhtml+xml podlegały drakońskiej obsłudze błędów. Jeśli na stronie internetowej pojawiłby się choćby jeden błąd składniowy — np. brak znacznika </head> albo nieprawidłowe zagnieżdżenie znaczników otwierających i zamykających — przeglądarki nie będą miały wyboru jak tylko zatrzymać proces przetwarzania i wyświetlić komunikat o błędzie na ekranie użytkownika.

Pomysł ten nie był zyskał wielkiej popularności. W świecie, w którym 99% stron internetowych zawiera błędy, groźba wyświetlania błędów na ekranach użytkowników uzasadniona zaledwie paroma usprawnieniami w XHTML 1.0 i 1.1, powodowała, że prawie nikt nie używał typu application/xhtml+xml. Jednak nie znaczy to, że całkowicie ignorowano XHTML. Co to, to nie. Dodatek C specyfikacji XHTML 1.0 dawał projektantom furtkę w postaci możliwości serwowania dokumentów XHTML jako typu MIME text/xhtml. I tysiące programistów korzystało z tej możliwości: stosowali składnię XHTML, ale używali typu MIME text/html.

Nawet dzisiaj istnieją miliony stron udających XHTML. Na początku mają deklarację typu dokumentu XHTML, nazwy znaczników są pisane z małej litery, wartości atrybutów znajdują się w cudzysłowach, a puste elementy są zamknięte za pomocą ukośnika, np. <br /> i <hr />. Jednak tylko niewielka część z nich jest serwowana jako typ MIME application/xhtml+html powodujący uruchomienie drakońskiej obsługi błędów. Strony z typem MIME text/html — niezależnie od deklaracji typu dokumentu, składni i stylu kodowania — są interpretowane przez „miłościwy” parser, ignorujący błędy i nie wyświetlający powiadomień na ekranie użytkownika, nawet jeśli strona jest niepoprawna.

Jednak omawiana furtka znajduje się tylko w XHTML 1.0. W XHTML 1.1 już jej nie ma i nie byłoby jej też w XHTML 2.0, gdyby go ukończono. Dlatego właśnie w internecie można znaleźć miliardy stron udających XHTML 1.0, a jedynie garstkę dokumentów w XHTML 1.1 (albo XHTML 2.0). Zatem czy naprawdę używasz XHTML-a? Sprawdź typ MIME. Właściwie, jeśli nie wiesz jakiego typu MIME używasz, to z dużym prawdopodobieństwem zgaduję, że jest to text/html. Dopóki serwujesz strony z typem MIME innym niż application/xhtml/+xml, w rzeczywistości z XML-em mają one wspólny jedynie kawałek nazwy.

Alternatywna wizja

W czerwcu 2004 r. konsorcjum W3C przeprowadziła warsztaty na temat aplikacji sieciowych i dokumentów złożonych. W warsztatach tych uczestniczyli przedstawiciele trzech przeglądarek, firmy programistyczne oraz inni członkowie W3C. Grupa zainteresowanych stron, włączając Mozilla Foundation i Opera Software, zaprezentowała swoją wizję przyszłości internetu: rozwój istniejącego standardu HTML 4.0 w celu dodania nowych elementów dla programistów nowoczesnych aplikacji sieciowych.

Poniższe zasady przedstawiają naszym zdaniem najistotniejsze wymagania dotyczące tych prac.

Zgodność wsteczna, łatwa migracja
Technologie aplikacji sieciowych powinny być oparte na znanych programistom technologiach, wliczając HTML, CSS, DOM i JavaScript. Podstawowe funkcje aplikacji sieciowych powinno dać się implementować za pomocą „zachowań”, skryptów i arkuszy stylów w IE 6 tak, aby projektanci mieli jasność, jak dokonać migracji. Wszelkie rozwiązania, których nie można zastosować w jednej z najpopularniejszych przeglądarek bez instalowania dodatków ma bardzo małą szansę powodzenia.
Jasno zdefiniowane zasady obsługi błędów
Zasady obsługi błędów w aplikacjach sieciowych muszą być dobrze zdefiniowane, tak aby nie trzeba było wymyślać własnych algorytmów ani podglądać rozwiązań konkurencji.
Użytkownicy nie powinni być narażeni na skutki błędów popełnianych przez programistów
Specyfikacje muszą dokładnie określać sposób postępowania w przypadku wystąpienia błędów w każdej możliwej sytuacji. Obsługa błędów powinna w głównej mierze polegać na „eleganckiej redukcji funkcjonalności” (jak w CSS), a nie radykalnym zakończeniu działania aplikacji (jak w XML).
Praktyczność
Każdy element specyfikacji aplikacji sieciowych powinien mieć praktyczne uzasadnienie. To jednak nie znaczy, że powinno też być na odwrót, tzn. nie każdy element, który może być praktyczny powinien zostać dodany. Przypadki użycia powinno się czerpać z prawdziwych stron internetowych, których twórcy wcześniej korzystali z nieefektywnych rozwiązań.
Stosowanie skryptów musi być dozwolone
Jednak należy ich unikać, gdy istnieje wygodniejsze rozwiązanie polegające na użyciu kodu deklaratywnego.
Należy wystrzegać się zawężania tylko do wybranych grup urządzeń
Przeglądarki dla komputerów stacjonarnych jak i urządzeń przenośnych powinny zawierać implementacje takich samych funkcji.
Otwartość
Internet zyskał na tym, że rozwijał się w sposób otwarty. Aplikacje sieciowe będą głównym składnikiem internetu i rozwój ich specyfikacji również powinien być otwarty. Listy mailingowe, archiwa oraz szkice specyfikacji powinny być zawsze publicznie dostępne.

Uczestnikom warsztatów zadano następujące pytanie: „Czy W3C powinna rozwijać rozszerzenia deklaratywne dla HTML i CSS oraz imperatywne dla DOM, aby zaspokoić wymagania aplikacji sieciowych średniego poziomu, w opozycji do wyrafinowanych i rozbudowanych API systemowych? (propozycja Iana Hicksona z Opera Software)”. Wynik głosowania wynosił 11 do 8 przeciw. W podsumowaniu warsztatów konsorcjum napisało: „Obecnie W3C nie zamierza angażować się w temat trzeciego głosowania: rozszerzenia dla HTML oraz CSS dla aplikacji sieciowych, inne niż technologie będące rozwijane w obecnych grupach roboczych”.

Postawieni przed takim faktem ludzie, którzy zaproponowali rozwój HTML i formularzy HTML mieli tylko dwa wyjścia: zrezygnować lub kontynuować prace poza strukturami W3C i wybrali tę drugą opcję rejestrując domenę whatwg.org. Tak w lipcu 2004 r. powstała grupa WHAT Working Group (WHATWG) (Grupa Robocza ds. Technologii Hipertekstowych Aplikacji Sieciowych).

Grupa robocza WHAT

Czym u diabła jest grupa robocza WHAT? Niech sami to wyjaśnią:

Grupa Robocza ds. Technologii Hipertekstowych Aplikacji Sieciowych (WHAT Working Group — WHATWG) jest nieoficjalną i otwartą grupą producentów przeglądarek oraz innych zainteresowanych stron. Celem grupy jest rozwój specyfikacji w oparciu o HTML i powiązanych technologii w celu ułatwienia tworzenia interoperacyjnych aplikacji sieciowych, z zamiarem wysyłania wyników prac do organizacji standaryzacyjnej. Efekty prac grupy mogą stanowić podstawę do rozszerzenia HTML-a na drodze formalnej.

Powstanie tego forum wynika z kilkumiesięcznej wymiany e-maili na temat specyfikacji dla tego typu technologii. Głównym tematem tych dyskusji do tej pory były rozszerzenia HTML 4 Forms o nowe funkcje zgłaszane przez autorów oraz ich stosowanie z zachowaniem zgodności z istniejącą treścią. Grupa ta została założona po to, aby zapewnić, że przyszły rozwój specyfikacji będzie całkowicie otwarty, dzięki prowadzeniu dyskursu w publicznej archiwizowanej liście mailingowej.

Kluczowe jest tu zachowanie zgodności. Język XHTML (pomijając dodatek C) nie jest zgodny z HTML. Wymaga stosowania nowego typu MIME i stosowana jest w nim drakońska obsługa błędów dla treści serwowanej z tym typem. Formularze XForms nie są zgodne z formularzami HTML, ponieważ mogą być serwowane tylko przy użyciu nowego typu MIME, co oznacza, że w nich również stosowane są drakońskie reguły obsługi błędów. Wszystkie drogi prowadzą do MIME.

Zamiast niweczyć ponad dziesięć lat pracy nad językiem HTML i powodować, że 99% stron stanie się bezużyteczne, grupa WHAT postanowiła zastosować inną strategię: udokumentowanie zasady działania algorytmów dopuszczających błędy, które były używane przez przeglądarki. Przeglądarki internetowe zawsze „wybaczały” wiele błędów w kodzie HTML, jednak nikt się nie kwapił aby dokładnie opisać, w jaki sposób to robiła. Przeglądarka Mosaic miała swoje własne mechanizmy radzenia sobie z błędami, a twórcy Netscape próbowali im dorównać. Później Internet Explorer próbował dorównać Netscape, a następnie Opera i Firefox starały się dostosować do Internet Explorera. Jeszcze później Safari dostosowywano do Firefoksa itd. aż do dzisiejszego dnia. W tym czasie programiści spędzili tysiące godzin próbując uczynić swoje produkty zgodnymi z produktami konkurencji.

Jeśli wydaje Ci się, że to wymaga ogromnej ilości pracy, to masz rację. Dokumentowanie sposobów interpretacji kodu HTML w sposób zgodny z istniejącą treścią (pomijając kilka rzadkich przypadków) zajęło grupie ponad pięć lat. W finalnym algorytmie nie ma ani jednego przypadku, w którym aplikacja miałaby przerwać wczytywanie kodu i wyświetlić powiadomienie o błędzie.

W tym samym czasie grupa pracowała jeszcze nad kilkoma innymi rzeczami. Jedną z nich była specyfikacja, początkowo zwana Web Forms 2.0, zawierająca definicje nowych typów kontrolek formularzy HTML (o formularzach dowiesz się więcej w rozdziale 10). Inną rzeczą nad którą pracowała grupa był szkic specyfikacji „Aplikacje sieciowe 1.0” zawierającej takie nowości, jak kanwa bezpośredniego rysowania grafiki i rodzima obsługa audio i wideo bez wtyczek.

Powrót do konsorcjum W3C

Przez dwa i pół roku konsorcjum W3C i grupa WHAT praktycznie ignorowały się nawzajem. W czasie gdy grupa WHAT pracowała nad formularzami sieciowymi i dodatkami do HTML-a, W3C zajmowało się językiem XHTML 2.0. Jednak w października 2006 r. było już jasne, że grupa WHAT nabrała dużego rozpędu, podczas gdy XHTML 2 był wciąż w powijakach, niezaimplementowany w żadnej z najważniejszych przeglądarek. W październiku 2006 r. Tim Berners-Lee, założyciel W3C, ogłosił, że konsorcjum W3C będzie współpracowało z grupą WHAT nad rozwojem standardu HTML.

Przez tych kilka lat wyjaśniło się sporo rzeczy. HTML powinien być rozwijany stopniowo. Próba przełączenia świata na XML, z obowiązkiem ujmowania wartości atrybutów w cudzysłowy, zamykania elementów pustych ukośnikiem oraz używania przestrzeni nazw, nie powiodła się. Przytłaczająca większość stron internetowych pozostała bez zmian, ponieważ przeglądarki nikogo nie zmusiły do ich wprowadzenia. Niektóre większe społeczności przeszły na nowe zasady i teraz korzystają z posiadania poprawnie zbudowanych dokumentów, ale to tylko niektórzy. HTML należy rozwijać stopniowo i jednocześnie kontynuować przemiany w kierunku poprawy budowy składniowej dokumentów.

Obecnie planowane jest utworzenie nowej grupy ds. HTML. W odróżnieniu od poprzedniej, ta grupa będzie pracować nad stopniowym rozwojem HTML-a, jak również równolegle będzie prowadzić prace nad XHTML-em. Działalność tej grupy jest popierana przez wiele stron, wliczając producentów przeglądarek.

Także formularze będą nadal rozwijane. Jest to złożona materia, ponieważ istnieją już języki formularzy HTML i XForms. Formularze HTML są wszechobecne, ale formularze XForms również zostały zaimplementowane i mają wielu użytkowników. W międzyczasie w specyfikacji Webforms zaproponowano kilka ciekawych rozwiązań dla formularzy HTML. Plan jest taki, aby rozszerzyć formularze HTML.

Jedną z pierwszych decyzji podjętych przez nową grupę roboczą W3C ds. HTML była zmiana nazwy Aplikacji sieciowych 1.0 na HTML5. I właśnie HTML5 jest tematem tej książki.

Dopisek

W październiku 2009 r. W3C rozwiązało grupę roboczą ds. XHTML 2 wydając następujące oświadczenie uzasadniające tę decyzję:

Kiedy konsorcjum W3C w marcu 2007 r. ogłosiło powstanie grup roboczych ds. HTML i XHTML 2, informowało, że będzie się przyglądać, czy istnieje zapotrzebowanie na XHTML 2. Konsorcjum zdaje sobie sprawę, jak ważny jest sygnał dla zainteresowanych, jak będzie wyglądała przyszłość HTML-a.

Podczas gdy doceniamy pracę wykonaną przez grupę roboczą ds. XHTML 2, po konsultacji z członkami organizacji zarząd W3C postanowił poczekać na wygaśnięcie projektu w 2009 r. i już go nie wznawiać.

Zwyciężają ci, którzy opracowują implementacje.

Zalecana lektura

Autor: Mark Pilgrim

Źródło: http://diveintohtml5.info/

Tłumaczenie: Mariusz Zdziech

Treść tej strony jest dostępna na zasadach licencji CC BY 3.0