Is HTML 5 by Apple really HTML 5?

(Ta notka jest także dostępna po polsku)

Apple recently released a number of demos, which they call HTML 5 demos. In this post, I’d like to analyze whether these demos are really HTML 5 or not. I am not going into ideological stuff here (but, to be honest, I do agree with Chris Blizzard’s point of view) – I’m going to check only the technological side of these demo pages.

One thing before we begin. Please note that the “long story short” sentences at the end of each paragraph relate to what I think is really demoed on each page, not to the formal presence of HTML 5 tags. For example, if a page uses HTML 5 section tags (and most of them do), but the demo itself is actually about style transitions, I do not consider it an HTML 5 demo. With this in mind, let’s start.

Video – indeed uses HTML 5 <video> tag, embedding an h.264 video file. Perspective and masking effects are not part of HTML 5, they are possible thanks to Apple’s experimental extensions to the CSS standard. So, this is indeed an HTML 5 demo, but not all the cool stuff here is actually HTML 5.
Long story short, HTML 5: yes, CSS 3: not really, Apple’s proprietary CSS extensions: yes.

Typography – HTML 5 has nothing to do with font embedding. Font embedding is standard CSS 2 (though only recently widely implemented by browser vendors). Horizontal slider is made out of plain old HTML 4 elements (mainly divs), instead of standard HTML 5 <input type=range> element, which is actually supported by Safari. Transparency works thanks to the widely supported CSS 3 Color Module opacity property. Rotation is powered by Apple’s experimental -webkit-transform property, which is actually supported by other browser vendors with their own prefixes (-moz-transform in Firefox 3.6 and -o-transform in latest Operas). Text shadow is applied through the text-shadow property from CSS 3 Text Module. It is also supported by Mozilla and Opera. No HTML 5 here other than <nav> and <section> elements, used throughout the demo site (though, there are lots of HTML4 <div>s there, too). You could make a basically identical page with plain old HTML 4, all the good stuff is, in fact, CSS 3 or experimental additions to CSS 3.
Long story short, HTML 5: not really, CSS 3: a bit, CSS 2: yes, Apple’s proprietary CSS extensions: yes.

Gallery – the only HTML 5 elements here, apart from <nav> and <section>, are <figure> elements, containg the image and prev/next buttons. All the cool stuff is actually made of Apple’s experimental CSS transforms and transitions (other browsers do support some or most of the same transforms and transitions with different vendor prefixes, i.e. Opera has -o-transition instead of -webkit-transition). While cool, these things are not standard yet, and never will be part of any HTML version – as they are extensions to CSS.
Long story short, HTML 5: a bit, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Transitions – are all about the same above-mentioned CSS transforms and transitions. HTML 5 is only used in the navigation part (the links starting off each transition are inside a <section> element, and the header is indeed an HTML 5 <header> element). The real part of the demo – the images that are transformed through CSS, are in plain old <div>s, though. All the coolness thanks to proprietary extensions to CSS.
Long story short, HTML 5: not really, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Audio – a real HTML 5 demo, uses <audio> and <canvas> HTML 5 elements. The song is in the proprietary and patent-encumbered MP4 format, though.
Long story short, HTML 5: yes. Whoohoo!

360° – a JavaScript script cycles through many images of the iPod touches as you move your mouse. Nicely done, but the only thing here that was not possible a few years ago is touchscreen compatibility thanks to Apple’s proprietary events souch as ontouchstart. If you ignore the touchscreen-related events, you can make an identical demo even in piece-of-crap browsers like IE 6 with little effort. So, as the touch events are the only really new thing here, it seems that this is in fact a demonstration of these iPod/iPad/iPhone-related touch events, not of any HTML 5 features.
Long story short, HTML 5: no, CSS 3: no, Apple’s proprietary events: yes.

VR – lots of Apple’s proprietary experimental CSS transforms and transitions shown here plus some JavaScript, but not much of HTML 5.
Long story short, HTML 5: not really, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Apple says:

The demos […] show how the latest version of Apple’s Safari web browser, new Macs, and new Apple mobile devices all support the capabilities of HTML5, CSS3, and JavaScript.

As you can see, with some exceptions (video/audio and canvas) and some marginal features outside of the core of each demo (navigation and sectioning), the real objective of these demos is to show Apple proprietary features, mostly CSS extensions. To be fair to the Cupertino company, some of them are pushed by Apple for standarization in the W3C, which is a good thing. Still, it does not make them standards at this moment, and once they become standards, they might look a bit or a lot diffrent.

There’s nothing inherently wrong in the demos themselves (and, as always with Apple, they are cool eye candy), but calling them “HTML 5” – while they do not show a lot of real HTML 5 features – and “standards” – while they’re mostly Apple’s proprietary non-standard extensions – seems to me slightly insincere. What is shown here is actually the great potential of the WebKit rendering engine. If they called it “Apple WebKit demos”, that would be correct and honest.

Post Scriptum for buzzword lovers: Of course, some people (like PPK) are trying to make a buzzword out of “HTML 5”, with meaning shifted from “HTML – the markup language and related APIs” to “all the cool new stuff without Flash”. If you’re one of those people, feel free to agree with Apple on this, and disagree with me.

PS #2. Am I an Apple hater? I wrote this on my MacBook… ;-)

Ile HTML 5 w HTML 5 – co właściwie pokazało Apple?

(This post is also available in English)

Apple udostępniło ostatnio kilka przykładów, które nazywa “demonstracjami możliwości HTML 5”. W tej notce chciałbym sprawdzić, czy faktycznie demonstrowane są tutaj możliwości HTML 5, czy może czegoś innego. Nie zamierzam tu zagłębiać się w ideologię (choć, szczerze mówiąc, całkowicie zgadzam się tutaj z Chrisem Blizzardem) – chcę się skupić wyłącznie na kwestiach technicznych.

Jeden drobiazg, zanim zaczniemy. Każde podsumowujące zdanie “krótko mówiąc” dotyczy tego, co moim zdaniem jest demonstrowane na danej stronie, a nie formalnej obecności znaczników HTML 5 w kodzie. Przykładowo, jeśli strona stosuje znaczniki sekcji HTML 5 (a większość z nich to robi), ale demo dotyczy tak naprawdę przejść (tranzycji) stylów, nie uważam jej za demo HTML 5. Mając to na uwadze – zacznijmy.

Video – faktycznie używa znacznika <video> HTML 5 do osadzenia pliku wideo w formacie h.264. Natomiast perspektywa i efekty maskowania nie są częścią HTML 5 – umożliwiają je eksperymentalne rozszerzenia CSS Apple’a. Tak więc jest to demo HTML 5, ale nie wszystkie fajne rzeczy w nim zawarte są częścią HTML 5.
Krótko mówiąc, HTML 5: tak, CSS 3: nie bardzo, rozszerzenia CSS Apple’a: tak.

Typography – HTML 5 nie ma nic wspólnego z osadzaniem czcionek. Osadzanie czcionek zostało opisane w specyfikacji CSS 2 (choć dopiero od niedawna jest to szerzej obsługiwane przez przeglądarki). Suwak poziomy został tutaj zbudowany ze starych elementów HTML 4 (głównie divów), nie wykorzystano tu standardowego elementu <input type=range> HTML 5, który jest obsługiwany przez Safari.
Przezroczystość działa dzięki szeroko dziś obsługiwanej własności opacity z CSS 3 Color Module. Rotacje umożliwia eksperymentalna własność CSS Apple’a -webkit-transform, która tak naprawdę ma swoje odpowiedniki w innych przeglądarkach – z innymi prefiksami producenta (-moz-transform w Firefoksie 3.6 i -o-transform w nowych Operach). Cień pod tekstem dołożony został przez własność text-shadow z CSS 3 Text Module. Jest to także obsługiwane przez Mozillę i Operę. Z wyjątkiem elementów <nav> i <section>, stosowanych we wszystkich stronach z tej grupy, nie ma tu nic z HTML 5 (mamy za to sporo <div>-ów z HTML 4). Można więc zrobić stronę wyglądającą i zachowującą się identycznie w starym dobrym HTML 4. Wszystkie bajery tutaj to tak naprawdę CSS 3 lub eksperymentalne rozszerzenia CSS Apple’a.
Krótko mówiąc, HTML 5: nie bardzo, CSS 3: trochę, CSS 2: tak, rozszerzenia CSS Apple’a: tak.

Gallery – poza <nav> i <section> z HTML 5 mamy tu tylko elementy <figure>, zawierające obrazki i przyciski prev/next. Ponownie, wszystkie bajery zapewniane są przez eksperymentalne rozszerzenia CSS Apple’a – transformacje (transforms) i efekty przejścia (transitions). Inne przeglądarki również to obsługują, ale z innymi prefiksami w nazwie, tj. Opera ma np. -o-transition w miejsce -webkit-transition. Fajnie to wygląda, ale nie jest to jeszcze ustandaryzowane i nigdy nie będzie częścią żadnej wersji HTML – jako że to rozszerzenia CSS.
Krótko mówiąc, HTML 5: trochę, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Transitions – to demko również dotyczy przejść i transformacji. HTML 5 używany jest tylko do nawigacji (linki odpalające przejścia są zawarte w elemencie <section>, a nagłówek – w HTML 5 <header>). Istotna część demonstracji – obrazki przekształcane przez CSS – siedzą w starych, dobrych <div>-ach. Wszystkie bajery pochodzą z rozszerzeń CSS Apple’a.
Krótko mówiąc, HTML 5: trochę, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Audio – w końcu prawdziwe demo HTML 5, używające elementów <audio> i <canvas> z HTML 5. Piosenka jest we własnościowym formacie MP4.
Krótko mówiąc, HTML 5: tak. Hurra!

360° – skrypt w języku JavaScript przełącza pomiędzy kolejnymi zdjęciami iPodów touch podczas przeciągania myszą. Fajnie zrobione, ale jedyna nowa rzecz tutaj, której nie można było zrobić dawniej, to zgodność z ekranami dotykowymi dzięki zdarzeniom takm jak ontouchstart, które są niestandardowym rozszerzeniem DOM Apple’a. Pomijając zdarzenia dla ekranów dotykowych, można przy niewielkim wysiłku zrobić identyczne demo działające nawet w badziewnych przeglądarkach jak IE 6. Jako że jedyną nowością są tu właśnie te zdarzenia dotykowe dla iPoda/iPada/iPhone’a, wydaje się, że właśnie ich pokazanie było celem tej demonstracji, a nie HTML 5.
Krótko mówiąc, HTML 5: nie, CSS 3: nie, własne zdarzenia Apple’a: tak.

VR – wiele różnych transformacji i przejść z eksperymentalnych rozszerzeń CSS Apple’a plus trochę JavaScriptu, ale niespecjalnie dużo HTML 5.
Krótko mówiąc, HTML 5: nie bardzo, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Apple mówi:

Te demonstracje […] pokazują, w jaki sposób najnowsza wersja przeglądarki Safari Apple’a, nowe Macintoshe i nowe urządzenia przenośne Apple’a obsługują funkcjonalności HTML5, CSS3 i JavaScriptu.

Jak widać, z kilkoma wyjątkami (video/audio i canvas) i mniej istotnymi częściami poza sercem każdego demo (nawigacja i sekcje), głównym ich celem wydaje się tutaj pokazanie własnych, niestandardowych funkcjonalności Apple’a, głównie rozszerzeń CSS. Owszem, część z nich Apple przekazało do W3C i są one obecnie standaryzowane, co jest istotnym plusem. Niemniej jednak, nie są one standardem na chwilę obecną, a kiedy już zostaną ustandaryzowane, mogą wyglądać nieco lub bardzo inaczej.

W samych demkach nie ma nic złego (i, jak zawsze u Apple’a, wyglądają super), ale nazywanie ich “demonstracjami HTML 5” – kiedy nie pokazują wiele z HTML 5 – i “demonstracjami standardów”, podczas gdy prezentują głównie niestandardowe rozszerzenia Apple’a – wydaje mi się trochę nieuczciwe. Co tutaj widać, to wielki potencjał silnika WebKit. Określenie tych stron “Demonstracją możliwości Apple WebKit” byłoby więc bardziej zgodne z rzeczywistością.

PS. Oczywiście, niektórzy (jak PPK) chcą uczynić z “HTML 5” tzw. buzzword, który nie ma znaczyć już “HTML – język znakowania oraz powiązane API”, tylko “wszystkie fajne nowe rzeczy bez Flasha”. Jeśli do nich należysz, masz prawo zgodzić się tutaj z Apple, a nie ze mną.

PS #2. Czy jestem wrogiem Apple? Napisałem tę notkę na MacBooku… ;-)

Mozilla Hacks: Grupowanie selektorów za pomocą -moz-any()

Poniższa notka pierwotnie pojawiła się w blogu Davida Barona (a następnie w Mozilla Hacks). Jak większość treści z MozHacks, zarówno oryginalny artykuł, jak i poniższe tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Funkcjonalność opisana poniżej pojawiła się w Mozilla Central (trunku) i obecnie dostępna jest tylko w conocnych testowych kompilacjach Firefoksa.

Grupowanie selektorów za pomocą -moz-any() w Firefoksie 4

Ostatniej nocy (tj. 23 kwietnia – przyp. tłum.) włączyłem do hg obsługę grupowania selektorów przy użyciu :-moz-any(). Umożliwia to stosowanie alternatywy pomiędzy kombinatorami, dzięki czemu nie trzeba dla każdego różniącego się kawałka selektora powtarzać wielokrotnie podobnych selektorów („any” po angielsku oznacza „dowolny”, tak więc zapis :-moz-any(ol, dir, ul) można czytać jako „dowolny spośród ol, dir i ul” – przyp. tłum.). Obsługa :-moz-any() pozwoliła nam na przykład zamianę tej regułki we wbudowanym w przeglądarkę domyślnym arkuszu stylów:

/* potrójnie (lub bardziej) zagnieżdżone listy nieuporządkowane
   wyświetają prostokąt przy każdym elemencie */
ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
  list-style-type: square;
}

na taką:

/* potrójnie (lub bardziej) zagnieżdżone listy nieuporządkowane
   wyświetają prostokąt przy każdym elemencie */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) ul,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) menu,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) dir {
  list-style-type: square;
}

Teoretycznie można to nawet uprościć do postaci:

/* potrójnie (lub bardziej) zagnieżdżone listy nieuporządkowane
   wyświetają prostokąt przy każdym elemencie */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir)
    :-moz-any(ul, menu, dir) {
  list-style-type: square;
}

…ale działałoby to wolniej, jako że taka regułka nie wpadłaby do kubełka ze znacznikami. (Jeśli :-moz-any() stanie się popularne, możemy dodać dodatkowy kod, dzięki któremu będzie to równie szybkie, ale na razie tego nie zrobiliśmy).

:-moz-any() może zawierać selektory zawierające wiele prostych selektorów (zgodnie z definicją prostych selektorów ze specyfkacji CSS 3 Selectors, w odróżnieniu od CSS 2.1), ale nie może zawierać kombinatorów ani pseudoelementów. Można zatem napisać: :-moz-any(p.warning.new, p.error, div#topnotice) albo :-moz-any(:link, :visited).external:-moz-any(:active, :focus), ale nie można wstawić div p ani div > p czy też :first-letter wewnątrz :-moz-any().

Przedrostek -moz- jest tu obecny z dwóch powodów. Po pierwsze, to tylko propozycja i nie znalazła się jeszcze w żadnej specyfikacji. Po drugie, nie jest to jeszcze kompletna konstrukcja, ponieważ na razie nie obsługuje poprawnie specyficzności.

Ciekawostka: -moz-any() przyda się w kontekście sekcji i nagłówków w HTML 5. Jako że elementy section, article, aside i nav mogą być zafnieżdżane, stylowanie wszystkich elementów h1 na różnych poziomach zagnieżdżenia może być – przy dotychczasowej składni – poważnie skomplikowane.

/* Poziom 0 */
h1 {
  font-size: 30px;
}
/* Poziom 1 */
section h1, article h1, aside h1, nav h1 {
  font-size: 25px;
}
/* Poziom 2 */
section section h1, section article h1, section aside h1, section nav h1,
article section h1, article article h1, article aside h1, article nav h1,
aside section h1, aside article h1, aside aside h1, aside nav h1,
nav section h1, nav article h1, nav aside h1, nav nav h1, {
  font-size: 20px;
}
/* Poziom 3 */
/* ...nawet o tym nie myśl! */

Zastosowanie -moz-any() znacznie upraszcza ten kod:

/* Poziom 0 */
h1 {
  font-size: 30px;
}
/* Poziom 1 */
-moz-any(section, article, aside, nav) h1 {
  font-size: 25px;
}
/* Poziom 2 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 20px;
}
/* Poziom 3 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 15px;
}

Mozilla Hacks: Interfejs FormData wkrótce w Firefoksie

W dzisiejszym odcinku tłumaczeń z Mozilla Hacks notka Paula Rogeta, jednego z głównych europejskich „ewangelizatorów” Mozilli, poświęcona interfejsowi FormData. Jak większość treści z MozHacks, zarówno oryginalny artykuł, jak i poniższe tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Interfejs FormData wkrótce w Firefoksie

Implementacja tego interfejsu pojawiła się w Mozilla Central (trunku) i dostępna jest aktualnie tylko w conocnych kompilacjach Firefoksa.

Specyfikacja XMLHttpRequest Level 2 (obecnie w wersji roboczej) dodaje nowy interfejs – FormData. Obiekty FormData umożliwiają tworzenie par klucz-wartość, reprezentujących pola formularzy i ich wartości, które można następnie łatwo przesłać w formacie “multipart/form-data” wykorzystując metodę send() obiektu XMLHttpRequest.

Dlaczego FormData?

W celu przesłania złożonych danych ze strony WWW do serwera (pliki, treści inne niż ASCII) konieczne jest stosowanie typu zawartości multipart/form-data. Zazwyczaj aby utworzyć formularz z takim typem, stosuje się kod jak poniżej:

<form method="post" 
    enctype="multipart/form-data" action="http://foo.bar/upload.php">
<input type="file" name="media"/>
<input name="nickname"/>
<input name="website"/>
<input type="submit" value="upload"/>
</form>

W ten sposób zwykle przesyła się pliki.

Firefox 3.6 umożliwił manipulację plikami z poziomu JavaScriptu (zob. File API [w jęz. angielskim – przyp. tłum.]), ale nie było dotąd prostego sposobu na przesłanie plików przez XMLHttpRequest. Odtworzenie funkcjonalności powyższego formularza z poziomu JavaScriptu było trudne, bo wymagało zakodowania treści do postaci multipart/form-data przez kod skryptu (np. ten kod, napisany przeze mnie [przez Paula Rogeta – przyp. tłum.] jakiś czas temu, implementuje kodowanie multipart/form-data: jest powolny i niezbyt elegancki).

Tutaj właśnie przydaje się FormData: do odtworzenia funkcjonalności przesyłania formularzy z poziomu JavaScriptu.

Obiekt FormData

Obiekt FormData pozwala ułożyć zbiór par klucz-wartość do przesłania przez XMLHttpRequest. Obiekt ten posiada tylko jedną metodę:

append(key, value);

Argument key to nazwa klucza dla przesłanej wartości, a wartość ta – value – może być ciągiem znaków lub plikiem.

Można utworzyć obiekt FormData, dołączyć do niego wartości i przesłać go z wykorzystaniem XMLHttpRequest. Aby zasymulować powyższy formularz, wystarczy:

// aFile może być plikiem z inputa z atrybutem type="file"
// albo plikiem przeciągniętym metodą drag&drop
var formdata = new FormData();
formdata.append("nickname", "Foooobar"); 
formdata.append("website", "http://hacks.mozilla.org");
formdata.append("media", aFile);
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://foo.bar/upload.php");  
xhr.send(formdata);

FormData i element <form>

Firefox (czy raczej silnik Gecko – przyp. tłum.) nieco rozszerza element <form> języka HTML o metodę getFormData(), która pozwala na pobranie danych formularza w postaci obiektu FormData. Nie jest to obecnie część standardu HTML, ale spodziewamy się, że pojawi się w niej w przyszłości (możliwe, że pod inną nazwą):

var formElement = document.getElementById("myFormElement");
var xhr = new XMLHttpRequest();
xhr.open("POST", "submitform.php");
xhr.send(formElement.getFormData());

Można także dodać dane do obiektu FormData pomiędzy pobraniem go z formularza a przesłaniem, jak poniżej:

var formElement = document.getElementById("myFormElement");
formData = formElement.getFormData();
formData.append("serialnumber", serialNumber++);
xhr.send(formData);

Pozwala to na modyfikację danych formularze przed przesłaniem, na przykład rozszerzając je o dodatkowe informacje, które nie są przeznaczone do edycji przez użytkownika w formularzu.

Zasoby (w jęz. angielskim):

Mozilla Hacks: Firefox 4 – nowy parser HTML5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Firefox 4: the HTML5 parser – inline SVG, speed and more. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.


Autorem wersji oryginalnej tej notki jest Henri Sivonen, zajmujący się nowym parserem HTML5 Firefoksa. Parser HTML jest jednym z najbardziej skomplikowanych i wrażliwych elementów przeglądarki. Steruje procesem przetwarzania kodu źródłowego HTML do stron WWW, dlatego też zmiany w nim wprowadzane są rzadko i muszą być dobrze przetestowane. Podczas gdy większa część silnika Gecko została przebudowana od czasów jego powstania w późnych latach 90., parser był jedną z rzeczy, które pozostały od samego początku niezmienne. Teraz kod ten został zastąpiony nowym, który jest szybszy, zgodny z nowym standardem HTML5 i daje sporo nowych możliwości.

Od jakiegoś czasu prowadziliśmy prace nad zastąpieniem starego parsera HTML w silniku Gecko. Nowy parser został ostatnio domyślnie włączony w trunku, tak więc wystarczy po prostu pobrać conocną kompilację przeglądarki, by wypróbować nowy parser bez potrzeby przełączania żadnych opcji konfiguracyjnych.

Cztery najważniejsze rzeczy, które są związane z nowym parserem HTML5:

  • można korzystać z kodu SVG i MathML bezpośrednio (inline) na stronach HTML5, bez przestrzeni nazw XML
  • przetwarzanie odbywa się poza głównym wątkiem interfejsu użytkownika Firefoksa, zwiększając całkowitą responsywność przeglądarki
  • szybkość zapisu własności innerHTML jest o około 20% większa
  • nowy parser naprawia dziesiątki starych błędów dotyczących przetwarzania.

Obejrzyj democonocnej kompilacji Firefoksa lub innej przeglądarce obsługującej HTML5. Powinno to wyglądać tak:

Co to jest?

Parser HTML5 w Gecko zamienia strumień bajtów w drzewo DOM, zgodnie z algorytmem przetwarzania HTML5.

HTML5 to pierwsza specyfikacja, która szczegółowo określa sposób parsowania HTML. Dotychczasowe specyfikacje nie opisywały, jak przekształcić strumień bajtów w drzewo DOM. Teoretycznie HTML przed HTML5 był określony jako aplikacja SGML. Pociągało to za sobą określony związek między kodem
źródłowym poprawnych dokumentów HTML i drzewem DOM. Jednakże przetwarzanie niepoprawnych dokumentów nie było dobrze określone (a strony WWW w większości składają się z niepoprawnego kodu HTML4), a jednocześnie istnieją konstrukcje SGML, które teoretycznie były częścią HTML, ale nie były implementowane w rzeczywistości przez popularne przeglądarki.

Brak właściwej specyfikacji sprawił, że twórcy przeglądarek musieli samemu dojść do tego, jak traktować nieprawidłowe dokumenty, w razie wątpliwości badając działanie innych przeglądarek o największym udziale w rynku (najpierw Mosaic, potem Netscape, potem IE). Powstało w ten sposób wiele niepisanych reguł, ale także wiele różnic w zachowaniu przeglądarek.

Algorytm przetwarzania HTML5 standaryzuje zachowanie, do którego zbiegają się przeglądarki i inne aplikacje konsumujące HTML. Zgodnie z projektem, algorytm przetwarzania HTML5 jest właściwy do przetwarzania istniejących treści HTML, tak więc aplikacje nie muszą dalej wspierać swoich starych parserów, aby móc wyświetlić stare treści. W conocnych kompilacjach Firefoksa parser HTML5 używany jest dla wszystkich treści typu text/html.

Jak inny jest nowy parser?

Algorytm przetwarzania HTML5 ma dwie główne części: tokenizację i budowanie drzewa. Tokenizacja jest procesem rozdzielania strumienia źródłowego do znaczników, tekstu, komentarzy i atrybutów wewnątrz znaczników. Faza budowania drzewa na bazie znaczników i tekstu pomiędzy nimi buduje drzewo DOM. Algorytm tokenizacji w parserze HTML5 bliższy jest temu, co robi Internet Explorer, niż temu, co robiły dotychczasowe wersje Gecko. IE miał przez długi czas dominację na rynku, przez co witryny były głównie testowane pod kątem prawidłowego działania z tokenizerem IE. Proces budowy drzewa natomiast jest zbliżony do dotychczasowego działania silnika WebKit. Spośród głównych silników przeglądarek przed HTML5, WebKit posiadał najbardziej rozsądne rozwiązanie problemu budowania drzewa.

Ponadto, nowy parser przetwarza strumienie poza głównym wątkiem. Tradycyjnie przeglądarki wykonywały większość zadań w głównym wątku. Radykalne zmiany, takie jak przeniesienie przetwarzania poza główny wątek, uprościły kod parsera HTML5 w porównaniu do starego parsera HTML Gecko.

Co nowego dla twórców witryn?

Zmiany omówione powyżej są interesujące głównie dla programistów przeglądarek. Kluczową cechą parsera HTML5 jest to, że właściwie nie widać, żeby cokolwiek się zmieniło.

Jest jednak jedna duża zmiana istotna dla twórców witryn: kod MathML i SVG bezpośrednio w dokumentach HTML5. Nowy sposób przetwarzania HTML5 uwalnia MathML i SVG od XML-a i udostępnia je w głównym formacie sieci WWW.

Oznacza to, że można osadzać złożone typograficznie wyrażenia matematyczne w dokumentach HTML, bez potrzeby przepisywania całego dokumentu do XHTML, jak też, co ważniejsze, bez potrzeby modyfikacji oprogramowania budującego witrynę do zwracania prawidłowo sformowanego kodu XHTML. Na przykład, aby osadzić w kodzie HTML wzór na rozwiązanie równania kwadratowego, wystarczy tylko poniższy kod:

<math>
  <mi>x</mi>
 
  <mo>=</mo>
  <mfrac>
    <mrow>
      <mo>&minus;</mo>
      <mi>b</mi>
      <mo>&PlusMinus;</mo>
      <msqrt>
        <msup>
 
          <mi>b</mi>
          <mn>2</mn>
        </msup>
        <mo>&minus;</mo>
        <mn>4</mn>
        <mo>&InvisibleTimes;</mo>
        <mi>a</mi>
 
        <mo>&InvisibleTimes;</mo>
        <mi>c</mi>
      </msqrt>
    </mrow>
    <mrow>
      <mn>2</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>a</mi>
 
    </mrow>
  </mfrac>
</math>

W podobny sposób można osadzić skalowalną grafikę SVG – bez przepisywania HTML-a do XHTML-a. Podczas gdy rozmiary ekranów i rozdzielczości stają się coraz bardziej zróżnicowane, coraz większą wagę przywiązuje się do jakości grafiki przy różnych stopniach powiększenia. Wprawdzie dotychczas można było używać grafiki SVG w dokumentach HTML przez referencję (używając elementu object), wstawianie SVG bezpośrednio jest w niektórych przypadkach wygodniejsze. Na przykład ikona ostrzeżenia może być teraz osadzona bezpośrednio, a nie ładowana z zewnętrznego pliku.

<svg height=86 width=90 viewBox='5 9 90 86' style='float: right;'>
  <path stroke=#F53F0C stroke-width=10 fill=#F5C60C stroke-linejoin=round d='M 10,90 L 90,90 L 50,14 Z'/>
  <line stroke=black stroke-width=10 stroke-linecap=round x1=50 x2=50 y1=45 y2=75 />
</svg>

Wystarczy utworzyć stronę zaczynającą się od <!DOCTYPE html> i wstawić do niej dwa powyższe fragmenty, a będzie to działać w nowych nocnych kompilacjach Firefoksa.

Ogólnie, jeśli mamy kod MathML czy SVG jako XML, wystarczy po prostu wkleić kod XML bezpośrednio do HTML-a (pomijając, jeśli istnieją, deklarację XML oraz doctype). Dwa zastrzeżenia: kod nie może stosować przedrostków przestrzeni nazw dla elementów (tak więc żadnych svg:svg ani math:math), a przedrostkiem przestrzeni nazw XLink musi być xlink.

W powyższych fragmentach MathML i SVG uważna osoba dostrzeże, że bezpośrednio osadzane fragmenty MathML i SVG są bardziej podobne do HTML i prostsze niż po prostu wklekony w to miejsce XML. Nie ma deklaracji przestrzeni nazw, a niepotrzebne cudzysłowy wokół wartości atrybutów zostały pominięte. Działa to, ponieważ znaczniki są tokenizowane przez tokenizer HTML5, a nie przez tokenizer XML. Pomijanie deklaracji przestrzeni nazw działa, ponieważ proces budowania drzewa nie używa atrybutów wyglądających jak deklaracje przestrzeni nazw do przypisania elementom “MathML-owatości” czy “SVG-owatości”. Zamiast tego <svg> rozpoczyna zasięg elementów, którym przypisana będzie przestrzeń nazw SVG w DOM, a <math> rozpoczyna zasięg elementów, którym w DOM przypisana będzie przestrzeń nazw MathML. W przykładzie MathML widać także, że stosowane są odwołania do encji nazwanych, które wcześniej nie były obsługiwane w HTML.

Poniżej krótkie podsumowanie przetwarzania MathML i SVG bezpośrednio w dokumentach HTML dla twórców witryn:

  • <svg></svg> przypisany jest do przestrzeni nazw SVG w DOM.
  • <math></math> przypisany jest do przestrzeni nazw MathML w DOM.
  • foreignObject oraz annotation-xml (na różnych mniej istotnych elementach) rozpoczyna zagnieżdżony zasięg HTML, tak więc można zagnieżdżać SVG, MathML i HTML w sposób, jakiego można oczekiwać.
  • Parser poprawia wielkość znaków w znakowaniu, tak więc <SVG VIEWBOX=’0 0 10 10′> działa w kodzie HTML.
  • Metody DOM i selektory CSS rozróżniają wielkość znaków, należy więc pisać wywołania DOM oraz selektory CSS z użyciem kanonicznej wielkości znaków, czyli tzw. camelCase w przypadku różnych części SVG, takich jak viewBox.
  • Składnia <foo/> otwiera i natychmiast zamyka element foo, jeśli jest to element MathML lub SVG (ale nie element HTML).
  • Tokenizacja atrybutów przebiega w taki sam sposób, jak w HTML, tak więc można pomijać cudzysłowy w sytuacjach, w których można byłoby je pominąć w HTML (tj. kiedy wartość atrybutu nie jest pusta oraz nie zawiera białych znaków, ", ', `, <, = ani >).
  • Uwaga: dwie powyższe cechy nie współgrają ze sobą dobrze z przyczyn zachowania zgodności z tokenizacją starego HTML-a. Jeśli cudzysłowy zostaną pominięte przy wartości ostatniego atrybutu, konieczne jest wstawienie spacji przed zamykającym ukośnikiem. Tak więc prawidłowy jest kod: <circle fill=green />, ale nieprawidłowy jest: <circle fill=red/>.
  • Atrybuty zaczynające się od xmlns nie mają absolutnie żadnych skutków, nie wpływają na obecność elementów ani atrybutów w danej przestrzeni nazw, tak więc nie ma potrzeby ich stosowania.
  • Atrybuty w przestrzeni nazw XLink muszą stosować przedrostek xlink (np. xlink:href).
  • Nazwy elementów nie mogą zawierać przedrostków ani dwukropków.
  • Zawartość elementów script w SVG tokenizowana jest tak, jak w XML – nie jak zawartość elementów script w HTML.
  • Kiedy element SVG lub MathML jest otwarty, sekcje <![CDATA[]]> działają tak, jak w XML. Można to wykorzystać do ukrycia treści tekstowych przed starszymi przeglądarkami nie obsługującymi SVG ani MathML w text/html.
  • Encje nazwane MathML dostępne są w całym dokumencie (także w treści HTML).
  • Aby zapewnić działanie stron, na których autorzy umieścili fragmenty SVG w HTML (nie wiadomo, po co) lub użyli znacznika <math> do celów niezwiązanych z MathML, próby zagnieżdżenia różnych popularnych elementów HTML jako elementów potomnych SVG (bez użycia foreignObject) spowodują natychmiastowe wyjście z kontekstu SVG lub MathML. Może to sprawić, że literówki będą miały zaskakujące efekty.