HTML5 kontra XHTML2 – Przyszłość Stron Internetowych
Opublikowano 01 stycznia 2009
Kategorie: Nowe technologie, Tworzenie stron, Wszystkie
0
Na początku był chaos. Tak można określić pierwsze lata rozwoju języka HTML. Jego historia sięga roku 1993, i choć już w dwa lata później czuwała nad nim organizacja W3C, w praktyce język ten rozwijany był również przez twórców przeglądarek (np. Netscape). Po 8 latach przerwy szykują się kolejne rewolucje w tworzeniu stron WWW.
W praktyce rekomendacje W3C (World Wide Web Consortium), skupiającego obecnie ponad 400 organizacji, firm, agencji rządowych i uczelni z całego świata, są respektowane dopiero od 1997 roku, kiedy opublikowano wersję 3.2 języka HTML, a pod koniec roku - 4.0. Od czasu wydania specyfikacji w wersji 4.01 w 1999 roku, niewiele się działo. Język ten wystarczał w pełni do tworzenia nowoczesnych na tamte czasy stron - to przeglądarki musiały nadrabiać braki w implementacjach. W 2000 roku światło dzienne ujrzał jeszcze XHTML 1.0, będący przeniesieniem HTML 4.01 do formatu zgodnego z XML i w zasadzie na tym skończył się rozwój języków służących do tworzenia stron WWW. Obecnie zgodność z którymś z tych dwóch (zwłaszcza z XHTML 1.0) języków przy walidacji w trybie Strict jest symbolem dobrych umiejętności webmasterskich. Wprawdzie w roku 2001 rekomendacją W3C stał się XHTML 1.1, ale nie przyjął się z powodu braku wsparcia ówczesnych przeglądarek.
Tak w skrócie wygląda historia języków hipertekstowych. Obecnie używamy rozwiązań sprzed 8 lat - nie trzeba chyba tłumaczyć, ile to jest w dziedzinie komputerów. Wraz z nadejściem Web 2.0 nastała pora rewolucji, lub przynajmniej ewolucji.
Tym razem do pracy wzięli się sami twórcy przeglądarek (Firefoxa, Opery i Safari) - założyli organizację WHATWG (Web Hypertext Application Technology Working Group), która od 2004 roku tworzy szkic języka Web Applications, będącego następcą HTML 4.01 i XHTML 1.x. Wreszcie w 2008 roku samo W3C opublikowało swój szkic języka HTML 5. Niepokojący był fakt, że nad przyszłością stron debatowały dwie organizacje o różnych poglądach. Mało tego, W3C opracowywało równolegle projekt XHTML 2.0! Na szczęście WHATWG szybko dogadało się z W3C (wiele osób zasiada w obu organizacjach) i obecna specyfikacja HTML 5 / Web Applications jest już tworzona wspólnie, choć nie planuje się połączenia tych organizacji. Częstszych zmian w specyfikacji dokonuje WHATWG, jednak to do W3C prawdopodobnie należeć będzie ostateczny głos.
Tym sposobem pozostał jedynie dylemat, w którym kierunku ma zmierzać rozwój sieci - HTML 5, czy może XHTML 2.0. Choć obecnie przyjmuje się, że języki te będą istnieć równolegle (co nie rokuje najlepiej na przyszłość), to HTML 5 ma być podstawą stron przyszłości. W praktyce w obu projektach można dostrzec sens i ciekawe rozwiązania. Zaznaczamy przy tym, że specyfikacje obu języków są w fazie szkicu i wiele może się jeszcze zmienić. Jednak po kilku latach prac, założenie zbliżenia obecnych wersji do finalnych jest jak najbardziej na miejscu. Z oficjalnymi rekomendacjami przyjdzie nam mimo to długo poczekać - W3C zdecydowało, że ogłosi je dopiero, gdy przynajmniej dwie przeglądarki będą w pełni wspierać dany język.
Co przyniesie HTML 5?
Przede wszystkim postawiono na kompatybilność wstecz. Oznacza to, że przeniesienie strony z HTML 4.01 lub XHTML 1.0 do HTML 5 ma w większości przypadków ograniczać się do zmiany znacznika odpowiadającego typowi dokumentu (DTD). Jeśli więc oczekiwaliśmy zerwania ze złymi rozwiązaniami przeszłości, tu tego nie uświadczymy. HTML 5 to bardziej ewolucja, niż rewolucja. Może to dziwić, bowiem przeglądarki wciąż będą obsługiwały stare DTD - nic więc nie stało na przeszkodzie, by posunąć się dużo dalej w zmianach. Niektórzy obserwatorzy komentują to jako błąd w samym założeniu kolejnego wcielenia HTML. Twórcy specyfikacji tłumaczą to faktem oddzielenia wymagań stawianych autorom stron od tych obowiązujących deweloperów przeglądarek. W ten sposób niektóre elementy są zabronione w użyciu przez webmasterów, ale przeglądarka musi je obsługiwać (by zachować wsteczną kompatybilność). Dzięki temu nie używa się już typowego “wycofywania” znaczników. Mimo to wydaje się, że wraz z przyjściem nowej technologii, prędzej czy później odejdzie stara. W przypadku wspierania przez HTML 5 składni HTML 4, zostawiamy za sobą złe nawyki, których może być się trudno pozbyć. Ciekawe natomiast zapowiada się samo połączenie HTML z XHTML. Będziemy więc mogli publikować treści przy użyciu HTML-a, jak również w formacie zgodnym z XML-em (mówimy wtedy o stronach budowanych w XHTML 5, co jest nazwą wybitnie nietrafioną). Oprócz zmian w znacznikach, HTML 5 standaryzuje sposób obsługi błędów przez przeglądarki. W specyfikacji HTML 4.01 nie było to jasno określone, skutkiem czego strony zawierające błędy inaczej wyświetlały się w różnych przeglądarkach. W zasadzie powstała w tym zakresie samowola, bowiem z założenia strony napisane z błędami w XHTML-u nie powinny się wcale wyświetlać, zaś strony w błędnym HTML-u miały być traktowane jako tzw. “zupa tagów” - czyli przeglądarka próbowała mimo wszystko wyrenderować treść najlepiej, jak potrafiła. W praktyce różnie to jednak bywało, dlatego w HTML 5 zdecydowano się zająć tym problemem.
Z nowości warto wyróżnić nową koncepcję modelu treści (zamiast znanych z HTML 4 elementów blokowych i liniowych), obsługę przeciągnij i upuść, funkcjonalność edytowania (ContentEditable) i cofania zmian (UndoManager), czy komunikację międzydokumentową (API postMessage). W znaczniku canvas dostaniemy pole do rysowania grafik i wykresów 2D - przeglądarki już obsługują tę funkcjonalność i jest to główny motyw przy pokazach i publikacjach na temat HTML 5.
Możliwe będzie przechowywanie danych na komputerze Internauty nie tylko w formie klucza i wartości, ale też w ramach bazy SQL. Dzięki temu możliwe stanie się szersze niż dotychczas używanie aplikacji WWW offline. Aplikacje będą miały również możliwość rejestrowania się do otwierania konkretnych typów mediów i używania protokołów.
Ze względu na strony zbudowane przy pomocy AJAX-a i Flasha zdecydowano się na udostępnienie historii przeglądania - teraz strony będą mogły dodawać tam wpisy, jednak pod restrykcyjnymi warunkami.
W samym modelu DOM Level 2 HTML wprowadzono także kilka dodatków do HTMLDocument i HTMLElement: zyskują getElementByClassName() do wybierania wszystkich elementów danej klasy i innerHTML do wprowadzania treści między znaczniki. HTMLDocument powie nam także przy pomocy hasFocus, czy dokument jest aktualnie w użyciu, zaś aktywować element będziemy mogli używając activateElement. Obiekt aktualnie używany zwróci nam getSelection(). Z kolei do samego HTMLElement dodano możliwość łatwiejszego kontrolowania klas - classList zaoferuje metody has(), add(), remove(), toggle(), dzięki którym będziemy mogli nijako katalogować klasy. Znaczniki a, area i link otrzymają podobny atrybut zwany reList, który pozwoli na sprawniejsze zarządzanie atrybutem rel.
Zmiany w znacznikach
W HTML 5 uproszczono kilka znaczników. Typ dokumentu zdefiniujemy teraz samym <!doctype html>, zamiast przykładowego starego <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">. Jest to zmiana na lepsze, bowiem nikt i tak nie znał na pamięć tego fragmentu kodu - powodował on tylko konieczność skopiowania tekstu z innego źródła. Zmiana ta jest już obsługiwana przez większość przeglądarek. Skróceniu uległ też tag meta odpowiedzialny za kodowanie znaków - zamiast długiego <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> teraz będziemy mogli wpisać intuicyjne <meta charset=”UTF-8”>.
Zmieniła się także rola tagu strong - będzie on teraz miał znaczenie czysto semantyczne, a nie wizualne. Znacznik small z kolei zmieni swoje znaczenie: ma być stosowany do przypisów bocznych i stopek redakcyjnych.
Nowe elementy
Nowe wcielenie HTML-a wprowadza znaczniki szczególnie przydatne w tworzeniu stron dynamicznych, jak blogi, czy portale społecznościowe. Widać ukierunkowanie zmian na dalszy rozwój Web 2.0.
Udostępniono znacznik section, którym możemy wyróżniać kolejne fragmenty dokumentu. Przykładowo możemy na blogu wyświetlić obok siebie wpisy z dwóch kategorii, każdą z nich zamykając w znaczniku <section> i tytułując przy pomocy <h1>. Warto przy tym wspomnieć, że znaczniki h1, ..., h6 miały wyjść z użycia na rzecz właśnie połączenia sekcji z jednym tylko znacznikiem <h>. Wycofano się jednak z tego pomysłu, mimo wciąż nieodpowiedniego stosowania h1, ..., h6 przez webmasterów.
Wracając do przykładu bloga, notki będziemy mogli umieszczać w tagu article, zaś poboczne notatki, niezwiązane z głównym tematem - w znaczniku aside. Dodając do tego elementy header i footer, otrzymamy szkielet strony. Dopełniają go znaczniki nav i menu, przy pomocy których stworzymy panel nawigacyjny strony.
Przyda się także element dialog do zobrazowania konwersacji między dwoma osobami. Oto, jak może wyglądać przykładowy kod z jego użyciem:
<dialog>
<dt> Witaj
<dt> Co robisz?
<dd> Czytam BlogTimes.pl
</dialog>
Znaczniki dt i dd służą do rozróżnienia rozmówców.
Do wyróżnienia fragmentu tekstu (np. w celu zrobienia przypisu na dole strony) posłuży nam mark.
Trochę mniej istotnymi tagami są time do reprezentowania czasu lub daty, meter do wyświetlania danych metrycznych (np. zajmowanej pamięci), ruby, rt i rb do tworzenia notatek pobocznych informujących np. o wymowie danego słowa.
Do przedstawiania treści tabelarycznej lub drzewiastej przyda się element datagrid. Zastanawia jego pierwsze zastosowanie - wszak mamy już tabele, więc może on zostać okrojony z tej funkcjonalności.
Z punktu widzenia wszechobecnej technologii AJAX, świetnym pomysłem jest wprowadzenie znacznika progress. W nim będziemy mogli umieszczać wszelkie sygnalizacje ładowania się danych lub dokonywania obliczeń. Może on także być wykorzystany przy tworzeniu preloadera na stronę, jak to ma miejsce w animacjach Flash.
Przy okazji komunikacji z serwerem warto wspomnieć o eventsource, w którym będziemy zawierać kod odpowiedzialny za stałe połączenie z serwerem (np. w przypadków chatów na stronach).
Odpowiedzi serwera, lub dowolne inne (wynikłe z obliczeń itp.) zaprezentujemy w znaczniku output - aż dziwne, że dotychczas takiej możliwości nie było.
Pokrewnymi tagami są command i bb. Pierwszy symbolizuje komendę, którą może uruchomić użytkownik, zaś drugi - taką samą komendę, ale dotyczącą przeglądarki (np. dodanie strony do ulubionych).
Z pewnością docenimy również nowe wartości atrybutu type znacznika input: datetime, datetime-local, date, month, week, time, number, range, email, url, search, color. Ich wprowadzenie oznacza, że pierwsze sprawdzenie podawanych przez użytkownika danych odbywać się będzie na poziomie i przy pomocy przeglądarki - zadba ona, by np. pole email zawierało faktyczny adres pasujący do wzorca. Jest to udogodnienie zwłaszcza dla Internautów, którzy nie będą już musieli czekać na przeładowanie strony tylko po to, by ujrzeć informację o złym formacie wpisanych danych. Jest to też rozwiązanie na wyłączony JavaScript, który zazwyczaj odpowiada za walidację danych po stronie klienta. Niestety wciąż pozostaną techniczne możliwości przesłania wartości niezgodnych z opisem, tyle, że już nie z poziomu przeglądarki. W praktyce więc webmasterzy wciąż będą musieli przeprowadzać sprawdzanie danych po stronie serwera.
Dla znacznika input przy ustawieniu atrybutu list możemy stworzyć specjalne komboboksy w powiązaniu z tagiem datalist. Przykładowo:
<input list=”browsers”>
<datalist id=”browsers”>
<option value=”Firefox”>
<option value=”Opera”>
</datalist>
Jeśli mamy gdzieś dostępne szczegóły, możemy zamknąć je lub przycisk je pokazujący w tagu details - będzie to bardzo przydatny znacznik.
Czasem mamy potrzebę dodać do artykułu film lub grafikę poboczną. W HTML 5 powinniśmy w tym celu posłużyć się znacznikiem figure i w nim zawrzeć pożądaną treść. Przykładowo:
<figure>
<video src=”ogg”></video>
<legend>Film</legend>
</figure>
Użyliśmy tu nowego znacznika - video. Jak można się spodziewać, do dyspozycji dostaniemy też audio. Jest to rozwiązanie dyskusyjne, bowiem te same możliwości oferuje tag object i jest to w zasadzie jego dublowanie. Z kolei w praktyce umieszczając plik dźwiękowy na stronie robimy to przy pomocy Flasha lub Silverlighta, więc jedyne nasuwające się sensowne zastosowanie znacznika audio to alternatywna treść paragrafu, np.
<audio src=”tekst_czytany.mp3”>
<p>Tekst</p>
</audio>
Nie jest pewna przyszłość tych dwóch elementów w kolejnych odsłonach szkicu HTML 5.
W dobie powstających gier online, które instalują pluginy do przeglądarek (np. QuakeLive) docenimy znacznik embed - właśnie on będzie służył do zamieszczania takich dodatków.
Nowe atrybuty
Znaczniki a i area zyskały nowe atrybuty: media i ping. Pierwszy jest odpowiednikiem tego stosowanego w przypadku tagu link, zaś ping przyda się zwłaszcza statystykom. Po kliknięciu na taki link, nie tylk zostaniemy skierowani na właściwą stronę, ale też zostaną wywołane zapytania do witryn o adresach podanych w tym atrybucie. Mogą to być na przykład właśnie linki do liczników statystycznych. Unikniemy dzięki temu obecnych, niezbyt praktycznych rozwiązań: wywołań JavaScriptu przed egzekucją końcowego linka, lub przekierowywania. Również dla tych dwóch znaczników wprowadzono na powrót atrybut target argumentując, że przydaje się w dzisiejszych aplikacjach webowych. Jest to sprawa dosyć dyskusyjna, bowiem ponownie odbieramy użytkownikowi kontrolę nad jego przeglądarką. Obserwatorzy naciskają, by nie wracać do złych praktyk.
Dla znacznika ol powrócono do atrybutu start (i dodano atrybut reversed do łatwego odwracania sortowania możliwości), natomiast dla li - do value. Powód jest taki, iż nie są to elementy czysto prezentacyjne. Można to uznać za plus.
Dla elementów pola input, sselect, textarea, button będziemy mogli ustawić autofocus (z wyjątkiem pól ukrytych). Co ważne, użytkownik będzie miał możliwość wyłączenia tej opcji.
Przydatna wydaje się też możliwość przypisania pól input, output, select, textarea, button do formularza nawet, jeśli nie są jego dziećmi w modelu DOM. Takie potrzeby faktycznie zdarzały się i nie było możliwości łatwego obejścia tego problemu.
Możemy również wymusić na użytkowniku uzupełnienie danych pól formularza już na poziomie przeglądarki za pomocą required. Podobnie mamy możliwość zrezygnować z walidacji danych pól przez przeglądarkę przy użyciu novalidate. W kwestii formularzy możemy je także dezaktywować bardziej globalnie - ustawienie disabled dla znacznika fieldset zagwarantuje wyłączenie wszystkich jego pól. Ponownie jest to uwolnienie się od JavaScriptu.
Problemem z JavaScriptem i AJAX-em było też synchroniczne wykonywanie czynności. Mianowicie, jeśli JavaScript coś ładował, nie mogliśmy pobierać czego innego w ramach otwartej strony (chyba, że stosowaliśmy specjalne sztuczki). Teraz wystarczy dodać do znacznika script atrybut async, by kod wewnątrz niego był wykonywany asynchronicznie w stosunku do innych elementów strony.
Zauważono też trend zapoczątkowany przez Google Gears, czyli dostępność stron w trybie offline. Przyszłościowo zaprojektowano atrybut manifest dla pola html, który będzie przechowywał link do wytycznych cache'owania strony w trybie offline.
Postarano się, by tag menu był wykorzystywany właściwie. W tym celu wprowadzono atrybuty type i label. W połączeniu z globalnym atrybutem (możliwym do przypisania do każdego elementu) contextmenu ma to dać narzędzie do tworzenia menu wyboru i kontekstowych.
Do dyspozycji przekazano także dwa nowe atrybuty dla iframe: seamless i sandbox, które mają pomóc odseparować pływające ramki od reszty treści. Ma to mieć zastosowanie np. przy publikowaniu notek na blogu w ramach iframe. W praktyce nie należy jednak spodziewać się zbyt częstego wykorzystania tego elementu.
Jak już wspomnieliśmy, pojawiły się nowe atrybuty globalne (możliwe do przypisania do każdego znacznika). Listę z HTML 4 uzupełnią class, dir, id, lang, style, tabindex, title oraz nowe: contenteditable (oznacza, że treść wewnątrz tagu można edytować), contextmenu (pozwala na używanie menu proponowanego przez autora strony), draggable (sygnalizuje element możliwy do przeciągania), hidden (element ukryty) oraz atrybuty definiowalne przez webmastera, które należy rozpocząć od data-.
Elementy usunięte
Jak już wspomnieliśmy, inne zasady obowiązują webmasterów, a inne - twórców przeglądarek. Mimo więc, że dla nas pewne elementy zostały usunięte, przeglądarki muszą je obsługiwać, by zachować kompatybilność wsteczną (chociaż nie zawsze ta obsługa będzie musiała przebiegać tak, jak dotychczas).
Z HTML 5 usunięto z powodu ich czysto reprezentacyjnej funkcji następujące tagi: basefont, big, center, font, s, strike, tt, u. Z kolei z powodu wprowadzania zamieszania i braku użyteczności zrezygnowano z ramek (poza ramkami pływającymi - iframe). Ze względu na podobne problemy zrezygnowano z acronym (do stosowania skrótów i akronimów należy stosować abbr), applet (jego miejsce zapełnia object), isindex (ma być zastąpiony innymi sposobami kontroli formularzy) oraz dir (na rzecz ul).
Jeśli będziemy tworzyć stronę jako HTML 5, wolno nam używać tagu noscript. Nie dotyczy to jednak stron tworzonych jako dokumenty XML, ponieważ jest to znacznik zależny czysto od parsera kodu HTML i nie należy do składni języka XML. Z tego powodu nie wolno stosować noscript w tym drugim przypadku.
Ze specyfikacji wypadło także mnóstwo atrybutów związanych z wyglądem dla niemal wszystkich znaczników. W szczególności nie będziemy mogli już stosować align, alink, link, text, vlink, background, bgcolor, border, cellpadding, cellspacing, char, clear, frame, height, hspace, marginheight, marginwidth, noshade, nowrap, rules, scrollig, valign, width. Jest to zdecydowanie krok naprzód, bowiem wszystkie te zadania są realizowalne przy pomocy kaskadowych arkuszy stylów - tak również brzmi rekomendacja w tej kwestii.
Nie uświadczymy również atrybutów: name dla img i a, language dla script (wystarczy podać sam typ), czy summary dla table. Dziwić może usunięcie atrybutu accesskey dla a, area, button, input, legend, textarea - jest szansa, że to ulegnie zmianie.
Co na to XHTML 2.0?
Niestety niewiele. Ostatnia zmiana w szkicu konkurencyjnego projektu datowana jest na lipiec 2006 roku. Od tego momentu prace wstrzymano na rzecz HTML 5. Powodem popularności tego ostatniego był... Internet Explorer. Konkretnie, obsługuje on wspomnianą wyżej “zupę tagów”, natomiast do niedawna zupełnie nie radził sobie z dokumentami XHTML (zamiast je wyświetlać, próbował pobrać na dysk). Większościowy udział tej przeglądarki w rynku spowodował, że XHTML 1.x nie zyskał wielkiej sympatii mimo, iż był bardziej rekomendowany przez W3C, aniżeli HTML 4.01. Tym sposobem doszło do dziwnej sytuacji, w której strony zbudowane w XHTML uchodziły za nowocześniejsze i bardziej odpowiednie do zastosowań profesjonalnych, a mimo to kolejne wcielenie XHTML-a nie wzbudziło większego zainteresowania. Z pewnością ogromny wkład w to ma również fakt, że XHTML 2.0 kreuje się na język dosyć skomplikowany i bardzo restrykcyjny, w dodatku niekompatybilny wstecz (a więc dosyć rewolucyjny).
W XHTML 2.0 zrezygnowano na przykład ze standardowych formularzy na rzecz XForms, które wprawdzie są bardziej elastyczne i przystępniejsze w walidacji, ale jednak wymagają nauczenia się ich użycia.
Również zbiór atrybutów obsługujących zdarzenia zostanie zastąpiony przez XML Events. Ponownie, jest to zmiana w dobrym kierunku (daje możliwość definiowania własnych zdarzeń), lecz komplikująca proces tworzenia strony.
Jest jednak też trochę zmian, które obserwatorzy chętnie by widzieli w HTML 5. Dla przykładu, niemal każdy element w XHTML 2.0 może zawierać atrybut href, tworząc tym samym link. Wydaje się to świetnym pomysłem. Przykładowo, możemy napisać: <li href=”index.php”>Start</li>.
Obrazy mają być wyświetlane w ramach znacznika object - już kiedyś W3C debatowało nad taką możliwością dla samego HTML-a, jednak nie zdecydowało się na podjęcie tego kroku.
Ciekawym natomiast jest połączenie atrybutu src z niemal każdym tagiem. Ma to być alternatywą dla alt - przykładowo: <p src="logo" type="image/png; image/gif;q=0.2">Tekst zamiast obrazka</p>. Daje to możliwość stosowania stylów dla tekstów alternatywnych, czego brakuje w HTML-u.
Znacznik odpowiedzialny za linię poziomą - hr - zostanie zastąpiony tagiem separator, który jest bardziej klarowny w swej nazwie. Będzie on mógł również przyjmować formę rozdzielnika wertykalnego.
Zauważono także problem odwoływania się do br w arkuszach stylów. Z tego powodu znacznik ten usunięto na rzecz l, który obejmować będzie jeden wiersz.
W znaczniku p będą mogły znaleźć się m.in. tabele - brak takiej możliwości był niewygodny w przypadku wcześniejszych wersji i odmian HTML-a.
Z bardziej interesujących elementów warto też wspomnieć listę nawigacyjną nl (HTML 5 ma tu
odpowiednik w formie menu) oraz standby, w którym zawrzemy dane wyświetlane w trakcie ładowania się strony lub robienia obliczeń.
Z kolei atrybut role daje dużo szersze możliwości definiowania struktury strony, niż same header i footer w HTML 5.
HTML 5 równy z XHTML 2.0
Obydwa języki mogą współistnieć. Widać bowiem tendencję XHTML-a do przekształcania się w język bardziej formalny, który przyda się w np. w urządzeniach mobilnych, gdzie nie ma miejsca na obsługę błędnych stron. Zanim jednak któryś z języków będzie w użyciu na co dzień, miną kolejne lata. HTML 5 posiada dużo szersze wsparcie społeczności webmasterskiej, aniżeli jego konkurent - jest niemal pewnym skutkiem ewolucji. Warto jednak trzymać rękę na pulsie, bowiem co jakiś czas pojawiają się absurdalne pomysły pokroju legalizacji użycia tagu font w przypadku treści generowanej z edytorów WYSIWYG online. XHTML 1.0 był już bliski ideału - przejrzysty i profesjonalny. HTML 5 to z kolei powrót do możliwości tworzenia stron przez amatorów, gdzie niezamykanie tagów nie stanowi większego problemu. Z tego względu dyskusja nad rozwojem sieci wciąż jest bardzo burzliwa, a końcowy efekt prac nad HTML 5 jest niepewny.
HTML5 w usługach Google
Google szybko zaczęło korzystać z dobrodziejstw HTML5. W lutym na kongresie Mobile World w Barcelonie zaprezentowano aplikacje Gmail i Google Maps oparte o nowy standard.
Eksperymentalna wersja Gmaila jest dostępna na urządzenia HTC Magic (znany także jako G2) i iPhone. W pierwszym przypadku do dostępu offline wykorzystywane jest cache'owanie listów na komórce przy pomocy Google Gears na Androidzie. Rewolucja zaczyna się dopiero przy iPhone, którego przeglądarka Safari oferuje już pełne wsparcie dla lokalnej bazy danych SQLite. Różnica między Google Gears a API bazy danych HTML5 polega na tym, że API Gears działa synchronicznie (wymaga dodatkowych wątków do realizowania zapytań do bazy), podczas gdy HTML5 database API jest asynchronicznie i używa callbacków. Można się więc spodziewać, że wraz z implementowaniem HTML5 w przeglądarkach projekt Gears będzie stopniowo wycofywany. Narazie zapowiedziano przepisanie mobilnej usługi Google Calendar na HTML5.
Z kolei dla urządzenia Palm Pre zaprezentowano nową wersję Google Maps, opartą o czysty HTML5. Dzięki GeoLocation strona działająca w przeglądarce może teraz uzyskać informacje o położeniu telefonu, więc nie ma już potrzeby budowania osobnej aplikacji dla tej usługi.