Podstawy#

Możliwości#

Standard HTML5 wprowadza sporo nowości na wielu płaszczyznach. Jak już wspomniałem nieco wcześniej, jest próbą uporządkowania poprzednich wersji specyfikacji (HTML4, XHTML 1.0 i DOM Level 2 HTML), z jednoczesnym uwzględnieniem potrzeb programistów aplikacji webowych. Dotyczy to również niektórych API (np. DOM Level 0), które nigdy nie zostały udokumentowane, ale są szeroko implementowane w programach oraz używane przez większość autorów stron WWW. Dlatego HTML5 można rozpatrywać w dwóch głównych kategoriach:

Obie drogi podziału przeplatają sie wzajemnie (na pewnym poziomie zaawansowania webmastera), ale możlliwe jest ich osobne scharakteryzowanie.

Bałagan#

Niezależnie ile wprowadzono nowości, ile wymyślono genialnych rzeczy, widać jak na dłoni, że wszysko zmienia się bardzo dynamicznie. Śledząc to wszystko odnoszę wrażenie, że im więcej osób (zainteresowanych grup) próbuje wcisnąć własne pomysły, tym większy bałagan generują. Na dzień dzisiejszy mamy dwa dokumenty, które jednocześnie przeznaczone są dla twórców implementacji, jak i deweloperów:

Specyfikacje publikowane przez WHATWG nie są identyczne z projektami W3C. Główna różnica jest taka, że WHATWG zawiera przyszłe rozwiązania, które W3C nie uwzględnia w obecnym projekcie (może pojawią się jako rewizje w przyszłych wersjach HTML). Ponadto, niektóre z funkcji zostały opisane przez W3C w osobnych dokumentach, kiedy WHATWG umieszcza wszystko w jednym pliku.

Już samo zerknięcie na spiś treści uświadamia jakimi "klocami" są owe dokumenty. Osoby odpowiedzialne za standardy zdały sobie z tego sprawę, dlatego w późniejszym czasie udostępniono wersje "odchudzone", ukierunkowane w szczególność na twórców stron WWW oraz programistów aplikacji webowych:

Pewna trudność w czytaniu tych dokumentów wynika z faktu, że nowy HTML5 definiowany jest w kategoriach DOM. Mamy mnóstwo odwołań do różnych obiektów, metod, interfejsów i innych zagadnień, które właściwie istotne są tylko przy pracy z językiem JavaScript. Kolejną kulą u nogi będą wytyczne dla twórców implementacji - materiał przeznaczony dla niewielkiej grupy ludzi, a mimo to znalazł się w specyfikacji i utrudnia jej analizę. Sytuacji nie jest w stanie uratować odchudzona wersja W3C (ta dla programistów), która tak naprawdę generowana jest automatycznie - usuwane są tylko wytyczne dla implementatorów, a cała reszta pozostaje bez zmian. Kompakcić od WHATWG wcale nie jest lepszy, w moim odczuciu jego aspekt wizualny jest tragiczny, już wolę analizować pełną wersję.

Kolejnym poważnym minusem owych dokumentów będą przykłady, a raczej ich brak (no może nie całkowity, ale przepychu nie uświadczymy). Mamy całą masę suchego tekstu, aż się prosi żeby większość zastąpić/uzupełnić po prostu przykładami. Widziałem kilka najnowszych modułów CSS3, niektóre rozwiązania nie należą do najłatwiejszych (mają rozbudowane techniczne definicje), ale dodatkowo umieszczono w nich ze 20 przykładów (często więcej), dzięki którym zrozumienie całości nie stanowi większego problemu. Szkoda, że standard HTML5 nie jest opisywany na podobnej zasadzie.

Jeśli ktoś nie jest w stanie przetrawić tak podanego materiału powinien poszukać innych źródeł. Istnieje cała masa ciekawych blogów, stron, prezentacji oraz kursów opisujących najnowsze zagadnienia w bardziej przystępny, a co najważniejsze, praktyczny sposób. Jedynym materiałem od W3C, który w mojej opinii nadaje się do przestudiowania dla zwykłego śmiertelnika, będzie:

Jest to zgrabny wykaz wszystkich elementów oraz najważniejszych uwag dotyczących składni HTML5. Niestety, brakuje w nim prostego opisu niektórych API, dlatego wiedzę o nich trzeba uzupełnić z innych źródeł.

Może w przyszłości ratunkiem dla początkujących będzie projekt Web Platform Docs, który ma doprowadzić do stworzenia jednolitej dokumentacji opisującej wykorzystywanie najnowszych technologii internetowych. W projekt zaangażowali się Adobe, Facebook, Google, Microsoft, Mozilla, Nokia i Opera zaś poparli go między innymi Apple i HP. Wszelkie działania odbywają się pod patronatem W3C. Strona w założeniach ma wyeliminować odwieczny problem deweloperów, czyli konieczność szukania rozwiązań pozwalających na dostosowanie internetowych treści do konkretnej przeglądarki lub urządzenia (takiego jak smartfon lub tablet) w wielu miejscach i potrzebę eksperymentowania. Tworzona właśnie dokumentacja ma wszelkie te różnice szczegółowo opisać i wskazać konkretny zestaw rozwiązań. Całość opiera się na systemie Wiki, dzięki czemu wszelkie zmiany można wprowadzać w sposób prosty i przejrzysty. Bardzo ambitne przedsięwzięcie, trzeba będzie chwilę poczekać, by przekonać się czy pomysł wypali, ale sama idea jest słuszna i należy jej kibicować.

Obawy o przyszłość#

Po raz kolejny do głosu dochodzą producenci przeglądarek, mieliśmy taką sytuację wiele lat temu. Ramki, animacje, migotania tekstu i inne wymysły pochodzą właśnie z tamtej epoki. Oczywiście nowy HTML5 wygląda na projekt bardziej przemyślany, ale ogrom nowości (które ciągle się pojawiają), w pewnym momencie może doprowadzić do rozłamu. Każda z grup pracujących przy głównych przeglądarkach zacznie wprowadzać własne pomysły, kiedy tylko zaobserwuje wyraźne zapotrzebowanie na dane rozwiązanie. Widać to po Google z jego przeglądarką Chrome, gdzie pojawia się najwięcej nowości, których wdrożenie nawet nie zostało potwierdzone przez pozostałe ekipy.

Wiele nowości wprowadzanych na szybko jest niedopracowane, ale z racji świerzości (i ogromnych możliwości) uzyskują dużą popularność. Pozostali producenci przeglądarek "miękkną", nie chcą pozostać w tyle i także adoptują nowe pomysły w swoich produktach. Rozpoczął się ogromny wyścig, którego celem będzie stworzenie jak najlepszej platformy dla aplikacji webowych. Mam dziwne przeczucie, że w pewnym momencie temat standardów zostanie zepchnięty na dalszy plan. Czyżby czekała nas powtórka z rozrywki?

Oczywiście to tylko moje zdanie, obym się mylił. Wróćmy jednak do tego, co na chwilę obecną wywołuje zachwyt dla większej części webdeweloperów.

HTML5 jako język znacznikowy#

Tutaj sytuacja jest dosyć klarowna - język HTML5 scharakteryzowano od nowa. Dotyczy to zarówno nowych poleceń jak i przetwarzania dokumentów.

Nowe polecenia#

Pojawiło się sporo nowych znaczników i atrybutów, które czynią dokumenty bardziej semantycznymi. Nie ma potrzeby stosowania dużej liczby nic nie znaczących elementów div czy span. W dużym skrócie można wymienić następujące nowości:

Jak widać zmian jest od groma. Powyższy wykaz dotyczy tylko nielicznych nowych i starych poleceń. Ale HTML5 to nie tylko polecenia, to określenie języka niejako na nowo.

HTML5 został tak skonstruowany, że starsze przeglądarki po prostu zignorują nowe polecenia. W bardzo szerokim zakresie zachowano kompatybilności wsteczną. Można to zaobserwować na przykładzie stron, które napisane zostały przy użyciu starszych rozwiazań.

Elementy prezentacyjne#

Niektórzy mogą się zastanawiać, dlaczego zachowano niektóre elementy prezentacyjne (np. b, i lub small). Pozostawienie tych poleceń jest w głównej mierze powodowane ich powszechnym użyciem, a także przydatnością w niektórych sytuacjach, gdzie zastosowanie bardziej znaczących (pod względem semantycznym) elementów jest niewłaściwe.

Istnieje wiele wspólnych przypadków użycia kursywy, która prawidłowo wprowadzana jest przez bardziej szczegółowe elementy, np. emfaza (em), cytat (cite), definicja (dfn) lub zmienna (var). Są też jednak takie, które nie są dobrze reprezentowane przez te elementy. Mogą być to opisy taksonomiczne, terminy techniczne, wyrażenia frazeologiczne, myśli, a nawet nazwy statków.

Podobnie jest w przypadku pogrubienia tekstu, które zostaje prawidłowo wprowadzone przez bardziej szczegółowe elementy, np. mocna emfaza (strong), nagłówki (h1-h6), czy nagłówki w tabeli (th). Istnieją jednak takie przypadki, które nie są dobrze reprezentowane przez te elementy. Przykładem mogą być słowa kluczowe w danej części dokumentu lub nazwy produktów w wykazie.

Część osób twierdzi, że w takich przypadkach należy wykorzystać elementy span z odpowiednią nazwą klasy zdefiniowaną w CSS. Jednakże elementy b oraz i zapewniają awaryjną stylizację w środowiskach, które nie obsługują arkuszy stylów, lub które nie wizualizują treści, np. czytniki ekranu. Elementy te pozwalają dostarczyć pewnych wskazówek, że tekst w nich umieszczony w jakiś sposób różni się od otaczającej zawartości.

W istocie elementy te przekazują wyraźny znak (choć nie semantyczny), że zawartość w jakiś sposób różni się od otoczenia. Interpretacja semantyczna pozostawiona zostaje dla programu przetwarzającego, i może być różna, w zależności od charakteru danego programu. Zostało to dokładnie wyjaśnione w specjlanym wpisie na blogu.

Analogiczna sytuacja występuje w przypadku znacznika small, który przeznaczony jest dla treści powszechnie wyświetlanej drobnym drukiem. Mogą być to prawa autorskie, zastrzeżenia i inne prawne adnotacje powszechnie spotykane na końcu dokumentu.

To jaka jest zatem różnica między omawianymi elementami a np. znacznikiem font. Elementy pokroju font są silnie uzależnione od rodzaju mediów (mają one zastosowanie do wizualnych przeglądarek, ale nie do przeglądarek głosowych). Tagi b, i i small zawsze określane były jako prezentacyjne, ale w nowym HTML5 zdefiniowano je w sposób niezależny od typu mediów. Przykładowo, element small może odpowiadać za szybkie przeczytanie reklamy na końcu audycji radiowej.

Sposoby serializacji#

Składnia HTML5 nie jest już oparta na SGML, pomimo podobieństwa do jego znaczników. Jest to nowe podejście, z deklaracją typu dokumentu podobną do tej z SMGL (<!DOCTYPE HTML>). DOCTYPE nie określa składni języka, nie musi odwoływać się do żadnego DTD, wpływa jedynie na tryb renderowania strony (obecność oznacza zgodność ze standardami). Nie będzie żadnego oficjalnego DTD dla HTML5, można skorzystać z eksperymentalnych wersji.

HTML5 umożliwia dwie metody serializacji (przedstawiania) dokumentu:

Serializacja HTML dotyczy dokumentów z typem MIME text/html. Odnosi się ona do składni określonej przez najnowszy standard HTML5. W tym wypadku dozwolone są wszystkie reguły, które były określone we wcześniejszych wersjach HTML (niektóre tagi zamykające są opcjonalne i atrybuty nie zawsze muszą mieć wartość w cudzysłowie). Co istotne, w tym trybie możliwe jest stosowanie składni XML, tam gdzie nie ma to żadnego wpływu na parsowanie (np. małe litery w znacznikach, zamykanie elementów pustych za pomocą />, wartości atrybutów w cudzysłowach, atrybuty logiczne z wartością itd.). Jeśli komuś bardziej przypadła do gustu składnia XML, może ją bez problemu stosować w dokumentach HTML5, nie będzie to błędem. Każdy dokument, którego typ MIME to text/html jest uważany za serializację HTML i musi być analizowany za pomocą parsera HTML.

Serializacja XML (lub XHTML) dotyczy tylko i wyłącznie dokumentów z typem MIME application/xhtml+xml lub application/xml. Odnosi się ona do składni określonej przez XML 1.0 i przestrzeni nazw (namespace) w XML 1.0. Jeśli w dokumencie XML stosuje się elementy w przestrzeni nazw HTML, to mówimy że zawiera XHTML-a. Jeśli głównym elementem (root) jest html w przestrzeni nazw HTML, to mamy do czynienia z dokumentem XHTML.

Co to oznacza w praktyce? Zazwyczaj nie ma potrzeby stosowania XHTML-a. HTML słany jako text/html ma wszystko, czego potrzeba przy tworzeniu nowoczesnych projektów. Możliwe jest nawet bezpośrednie osadzanie języka SVG oraz MathML. Obydwa tryby (HTML oraz XML) zawierają niemal identyczne odwzorowanie w drzewie DOM - udostępniają w razie potrzeby sposoby, które pozwalają uzyskać pełną zgodność między nimi.

XHTML (lub jak inni określają XHTML5) musi być koniecznie słany z odpowiednim typem MIME (nie może być to text/html). Deklaracja DOCTYPE w tym wypadku jest opcjonalna, ale zasadniczo nie jest zalecana, ponieważ ma to jedynie znaczenie przy walidacji w parserach walidacyjnych, których przeglądarki i tak nie stosują (mają własne narzędzia przetwarzające). Stosowanie niewłaściwego typu MIME dla XHTML spowoduje, że dokument będzie parsowany według wymogów stawianych dla HTML. Innymi słowy, będzie traktowany jak "zupa tagów" (tag soup).

Należy pamiętać, że XML (a w konsekwencji XHTML) ma większe wymagania odnośnie składni. Błędne dokumenty zostaną odrzucone, zamiast treści zwrócony zostanie komunikat o błędzie. Ponadto możliwe jest osadzanie dowolnego języka XML, wystarczy określić odpowiednią przestrzeń nazw. Jeśli ktoś koniecznie musi sięgnąć po bardziej egzotyczne języki znacznikowe, powinien zastosować tryb XML.

Istnieje kilka technik jednoczesnego stosowania HTML5 oraz XHTML5 w projekcie. Wszystkie metody zostaną omówione w dalszych częściach kursu.

Czyli można powiedzieć, że nowy HTML5 udostępnia dwa tryby pracy, nie zabija on w żaden sposób XHTML-a. Niejako ułatwia migrację z trybu HTML do XML ponieważ:

Bardzo dobre podejście, które wreszcie porządkuje kwestię z wiecznie problematycznym XHTML-em, a raczej z programistami, którzy niewłaściwie stosowali ten język.

Jeśli ktoś ma wątpliwości co do możliwości stosowania składni XHTML w najnowszym standardzie HTML5 powinien przeczytać jeden z początkowych podtytułów specyfikacji.

Rozszerzalność#

HTML5 nie jest ograniczony przez DTD (który nie obsługiwał przestrzeni nazw). Nowy standard ma bezpośrednie wsparcie dla SVG i MathML nawet w trybie text/html. Możliwe jest także rozszerzenie semantyki przez zastosowanie mikrodanych (microdata). HTML5 pozwala także dodawać własne prywatne atrybuty data-* do każdego elementu. W trybie application/xml można stosować dowolne przestrzenie nazw, czyli korzystać z dowolnego wariantu języka XML. Mechanizmów rozszerzających język HTML5 jest naprawdę sporo, dobór odpowiedniego rozwiązania będzie zależał od sytuacji.

Obsługa błędów#

HTML5 (w trybie text/html) określa dokładny sposób obsługi błędów składni (czego nigdy nie ustalono w HTML 4.01). Jest to niezbędne, ponieważ w praktyce większość dokumentów umieszczonych w Sieci jest napisanych błędnie. Dzięki temu przeglądarki będą w jednolity (spójny) sposób obsługiwały zepsute dokumenty. Opis interpretacji błędów nie jest zezwoleniem na robienie ich. Dokumenty z błędnie stosowanym językiem HTML5 są uważane za niezgodne ze standardem.

Problem błędnych dokumentów rozwiązuje się sam w trybie XML. W tym przypadku nie ma miejsca na zrobienie choćby jednego błędu. Mi osobiście takie podejście odpowiada (o czym już pisałem wielokrotnie), ale nie wszyscy są w stanie osiągnąć tak wysoko zawieszoną poprzeczkę.

Prędkość i trudność parsowania#

Można dywagować, który tryb przetwarzania dokumentu jest szybszy. W praktyce jednak obie metody się równoważą.

W przeszłości parsowanie błędnego HTML-a było bardzo trudne, ponieważ nie było żadnej dokumentacji opisującej jak należy trakotwać błędy. Producenci oprogramowania wdrażali własne sposoby radzenia sobie z takimi dokumentami. Najnowszy HTML5 rozwiązuje problem przez jasne określenie obsługi błędów (patrz wyżej).

Prędkość parsowania HTML5 (tryb text/html) jest podobna do prędkości parsowania XML bez DTD. Zasadniczy sposób parsowania jest identyczny. Automatyczne zamykanie tagów ma koszt taki sam, jak sprawdzanie, czy wszystkie tagi zostały zamknięte. Parsowanie XML ma też swoje utrudnienia, np. mapowanie prefiksów i przestrzeni nazw.

Parsowanie XML z obsługą DTD (potrzebne do rozpoznania encji nazwanych) jest wolniejsze i trudniejsze od parsowania HTML5, ponieważ poza parserem XML wymaga także napisania/użycia parsera DTD do wczytania informacji o encjach. Parser musi być w stanie ściągnąć pliki z w3.org (robiąc DDoS) lub obsługiwać katalog DTD. Dlatego w projektach lepiej stosować tylko i wyłącznie encje numeryczne.

HTML5 platformą dla aplikacji webowych#

Tutaj dopiero rozpoczyna się sens całej "rewolucji". HTML powstał jako język dla dokumentów, a mimo to zaczął być używany do tworzenia aplikacji webowych i nie tylko. Niestety jego możliwości były bardzo ograniczone. Często (jak nie zawsze) trzeba było sięgać po zewnętrzne dodatki.

Wraz z rozpoczęciem prac nad HTML5 gruntownie zabrano się za przebudowanie i rozwinięcie różnych interfejsów (API) w przeglądarkach internetowych. Cel był bardzo jasny, maksymalnie ograniczyć przydatność zewnętrznych pluginów takich jak Adobe Flash, Microsoft Silverlight, Apache Pivot i Sun JavaFX.

Żeby skorzystać ze wszystkich dobrodziejstw towarzyszących językowi HTML5 koniecznym staje się znajomość języka JavaScript. Ten język skryptowy jest motorem napędowym w całej machinie. Można powiedzieć, że do swobodnego tworzenia aplikacji należy znać następujące technologie:

Im nowsze wersje powyższych języków przyswoimy, tym lepszy kod będziemy generować (zarówno pod względem budowy jak i możliwości). Nie wykluczone, że przy niektórych projektach będzie trzeba sięgnąć po całe zaplecze po stronie serwera (dobór serwera, wybór języka, wybór bazy danych, optymalizacja, bezpieczeństwo i wiele więcej istotnych spraw). Dopiero teraz możemy przyjrzeć się poszczególnym interfejsom.

Pierwsza kwestia to sprawa specyfikacji. Grupa WHATWG opisuje wszystko w jednym miejscu, bez szczególnego podziału oraz wersjonowania opisów. W3C przeniosła niektóre API do osobnych dokumentów, a część z nich pozostawiono w specyfikacji HTML5 W3C (jako jeden z rozdziałów). Z początku może to wprowadzać lekki zamęt. Każdy niech sam zdecyduje, która forma dokumentów będzie dla niego odpowiednia. W poniższej tabeli zamieszczam wykaz najistotniejszych interfejsów.

APIOdwołanie w specyfikacji WHATWGOdwołanie w specyfikacjach W3C
Canvas 2D ContextThe canvas elementHTML Canvas 2D Context
Drag and dropDrag and dropDrag and drop
MicrodataMicrodataHTML Microdata
Offline Web applicationsOffline Web applicationsOffline Web applications lub Offline Web Applications
Web WorkersWeb WorkersWeb Workers
Web SocketsWeb SocketsThe WebSocket API
Web StorageWeb StorageWeb Storage
IndexedDBIndexed Database API
File APIFile API
File Writer APIFile API: Writer
FileSystem APIFile API: Directories and System
GeolocationGeolocation API Specification
XMLHttpRequest Level 2XMLHttpRequest Level 2
Server-sent eventsServer-sent eventsServer-Sent Events
Web MessagingCross-document messaging i Channel messagingHTML5 Web Messaging

Powyższy wykaz prezentuje najważniejsze usprawnienia (jest tego więcej), które w zdecydowanej większość już teraz są zaimplementowane przez aktualne przeglądarki. Operowanie nowymi interfejsami na niskim poziomie może być uciążliwe, dlatego w razie problemów można poszukać odpowiednich bibliotek (z dnia na dzień ich liczba stale się powiększa). Nie należy zapominać także o CSS3, który wprowadza wiele ciekawych rozwiązań i może być przydatny przy tworzeniu lekkich i ładnie prezentujących się aplikacji webowych.

Kolejną istotną sprawą będą najnowsze plany i pomysły. Przykładem może być interfejs WebGL grupy Khronos. Pozwala on wyświetlać grafikę 3D w elemencie canvas. Już teraz można zagrać w Quake II wprost w przeglądarce internetowej Google Chrome lub Safari. Interesująco zapowiadają się EcmaScript 6 (bardzo wiele ważnych nowości) oraz nowsze moduły CSS.

Do tego dochodzą usprawnienia i dodatkowe znaczniki do już istniejącego języka HTML5. Może być to np. element device umożliwiający dostęp do takich urządzeń jak kamerka internetowa, mikrofon czy pendrive, Web Audio API lub Audio Data API (nagrywanie i edycja dźwięków), standaryzacja wielodotyku (multitouch), gestów oraz zmiany orientacji urządzeń mobilnych, które niekoniecznie mogą zostać przyjęte i upowszechnione w każdej przeglądarce.

Kompatybilność#

Tutaj zaczynają się lekkie schody. Ogrom nowości sprawia, że nie zawsze każde rozwiązanie pojawi się we wszystkich przeglądarkach. Przykładem może być tutaj Web SQL Database, czyli interfejs bazodanowy oparty o język SQLite. Nie jest on wspierany przez przeglądarkę IE oraz Firefox. Mozilla stanowczo stoi na stanowisku, że nigdy nie zaimplementuje tego interfejsu w Firefoksie (zaleca stosowanie IndexedDB).

Dlatego należy ostrożnie podchodzić do każdego nowego API. Jeśli zależy nam na jak najszerszej kompatybilności między programami powinniśmy wybierać te interfejsy, które obsługiwane są (lub będą) przez docelowe przeglądarki. Trzeba na bieżąco obserwować stanowiska poszczególnych producentów przeglądarek dla każdego API, żeby praca wykonana przy wdrożeniach nie poszła na marne.

Podsumowanie#

Można powiedzieć, że jest czego się uczyć przez kolejnych kilka lat. Sporo nowinek opracowanych razem z HTML5 na bieżąco wdrażano w najnowszych programach. Jednocześnie zabrano się za pracę nad następnymi wydaniami języków HTML, CSS, JavaScript, DOM oraz rozwojem dodatkowych API, przez co zakres materiału ulega nieustannemu rozszerzaniu. Opanowanie wszystkiego ze szwajcarską precyzją z pewnością łatwe nie będzie. Należy cierpliwie rozwijać własne zainteresowania w segmencie, który sprawia nam najwięcej radości przy tworzeniu kodu, jednocześnie zwiększając jego elastyczność i możliwości.

Pasek społecznościowy

SPIS TREŚCI AKTUALNEJ STRONY

Podstawy (H1) Możliwości (H2) Bałagan (H3) Obawy o przyszłość (H4) HTML5 jako język znacznikowy (H3) Nowe polecenia (H4) Elementy prezentacyjne (H4) Sposoby serializacji (H4) Rozszerzalność (H4) Obsługa błędów (H4) Prędkość i trudność parsowania (H4) HTML5 platformą dla aplikacji webowych (H3) Kompatybilność (H4) Podsumowanie (H3)