Mark Pilgrim

Ponořme se do HTML5

Vydavatel:

CZ.NIC, z. s. p. o.

Milešovská 5, 130 00 Praha 3

Edice CZ.NIC

www.nic.cz

1. vydání, Praha 2014

Kniha vyšla jako 10. publikace v Edici CZ.NIC.

978‒80‒88168‒07‒2

© 2009–2011 Mark Pilgrim

Toto autorské dílo podléhá licenci Creative Commons (creativecommons.org/licenses/by-nd/3.0/cz), a to za předpokladu, že zůstane zachováno označení autora díla a prvního vydavatele díla, sdružení CZ.NIC, z. s. p. o. Dílo může být překládáno a následně šířeno v písemné či elektronické formě, na území kteréhokoliv státu.

Mark Pilgrim

Ponořme se do HTML5

Edice CZ.NIC

Obsah

Předmluva vydavatele

Pět věcí, které byste měli vědět o HTML5

1. Není to jedna velká věc

2. Nemusíte nic vyhazovat

3. Začít je snadné

4. Už to funguje

5. Už tu s námi zůstane

1. Jak jsme se sem dostali

1.1 Začínáme

1.2 Typy MIME

1.3 Delší odbočka na téma tvoření standardů

1.4 Nepřerušená linie

1.5 Historie vývoje html mezi lety 1997 a 2004

1.6 Všechno, co víte o xhtml, je špatně

1.7 Konkurenční vize

1.8 Pracovní skupina what?

1.9 Zpátky k W3c

1.10 Postskriptum

1.11 K dalšímu čtení

2. Detekce prvků HTML5

2.1 Začínáme

2.2 Techniky detekce

2.3 Modernizr, detekční knihovna

2.4 Plátno

2.5 Text na plátně

2.6 Video

2.7 Formáty videa

2.8 Místní úložiště

2.9 Web Workers

2.10 Offline webové aplikace

2.11 Geolokace

2.12 Vstupní typy

2.13 Placeholder (zástupný text)

2.14 Autofokus formulářů

2.15 Mikrodata

2.16 History api

2.17 K dalšímu čtení

3. Co to všechno znamená?

3.1 Začínáme

3.2 Doctype

3.3 Kořenový prvek

3.4 Prvek <head>

3.5 Znakové sady

3.6 Vztahy k odkazu

3.7 Rel = stylesheet

3.8 Rel = alternate

3.9 Další vztahy k odkazu v HTML5

3.10 Nové sémantické prvky v HTML5

3.11 Dlouhá odbočka na téma „jak prohlížeče zacházejí s neznámými prvky“

3.12 Hlavičky

3.13 Články

3.14 Data a časy

3.15 Navigace

3.16 Zápatí

3.17 K dalšímu čtení

4. Říkejme tomu vykreslovací prostor

4.1 Začínáme

4.2 Jednoduché tvary

4.3 Souřadnice plátna

4.4 Cesty

4.5 Text

4.6 Přechody

4.7 Obrázky

4.8 A co Ie?

4.9 Úplný příklad ze života

4.10 K dalšímu čtení

5. Video na webu

5.1 Začínáme

5.2 Videokontejnery

5.3 Videokodeky

5.4 Zvukové kodeky

5.5 Co funguje na webu

5.6 Problémy s licencováním videa H.264

5.7 Kódování videa pomocí videokonvertoru Miro

5.8 Kódování videa Ogg pomocí Firefoggu

5.9 Hromadné kódování videa Ogg pomocí ffmpeg2theora

5.10 Kódování videa H.264 pomocí HandBrake

5.11 Hromadné kódování videa H.264 pomocí HandBrake

5.12 Kódování videa WebM pomocí ffmpeg

5.13 A konečně kód

5.14 Typy MIME pozvedají hlavu

5.15 A co IE?

5.16 Problémy na iPhonech a iPadech

5.17 Problémy na zařízeních s Androidem

5.18 Úplný příklad ze života

5.19 K dalšímu čtení

6. Jste tady (a všichni ostatní taky)

6.1 Začínáme

6.2 Geolokační API

6.3 Ukažte mi kód

6.4 Ošetřování chyb

6.5 Výběr! Dejte mi na výběr!

6.6 A co IE?

6.7 Na pomoc přichází geoPosition.js

6.8 Úplný případ ze života

6.9 K dalšímu čtení

7. Minulost, současnost a budoucnost místního úložiště pro webové aplikace

7.1 Začínáme

7.2 Stručná historie hacků pro místní úložiště před HTML5

7.3 Představujeme úložiště HTML5

7.4 Používání úložiště HTML5

7.5 Sledování změn v úložišti HTML5

7.6 Omezení v současných verzích prohlížečů

7.7 Úložiště HTML5 v akci

7.8 Víc než jen dvojice klíč-hodnota: soupeřící vize

7.9 K dalšímu čtení

8. Hoďme to offline

8.1 Začínáme

8.2 Cache manifest

8.3 Tok událostí

8.4 Umění odstraňování chyb, aneb „Zabijte mě někdo!“

8.5 Vytvořme si nepřipojenou aplikaci

8.6 K dalšímu čtení

9. Forma šílenství

9.1 Začínáme

9.2 Zástupný text

9.3 Autofokus polí

9.4 E-mailové adresy

9.5 Webové adresy

9.6 Čísla jako číselníky

9.7 Čísla jako posuvníky

9.8 Výběr data

9.9 Vyhledávací pole

9.10 Výběr barev

9.11 Validace formulářů

9.12 Povinná pole

9.13 K dalšímu čtení

10. „Distribuovaná“, „rozšiřitelnost“ a další působivá slova

10.1 Začínáme

10.2 Co jsou mikrodata?

10.3 Datový model pro mikrodata

10.4 Označování osob

10.5 Označování organizací

10.6 Označování událostí

10.7 Označování recenzí

10.8 K dalšímu čtení

11. Upravujeme historii pro zábavu a zisk

11.1 Začínáme

11.2 Proč

11.3 Jak

11.4 K dalšímu čtení

Dodatek A: Vyčerpávající téměř abecední návod k detekování čehokoliv

K dalšímu čtení

Předmluva vydavatele

Vážení čtenáři,

po sérii knížek zaměřených převážně na běžného uživatele Internetu se v Edici CZ.NIC opět vracíme k tématu, které bude blízké zejména vývojářům internetových aplikací. A nevybrali jsme si pro tento návrat nic menšího než jazyk HTML, jeden ze základních stavebních kamenů konceptu WWW, který byl bezpochyby hlavním strůjcem rozmachu Internetu na přelomu tisíciletí. Zdá se, že po krátkém období nejistoty, jakým směrem se vývoj HTML bude ubírat, chytá tento jazyk druhý dech. Na podzim loňského roku došlo ke standardizaci HTML5 a o této nejnovější verzi jazyka pojednává právě tato kniha. V roce, kdy HTML slaví 25. výročí své existence, je již zřejmé, že nová verze bude akceptována hlavními hráči a postupně vytlačí některé proprietární technologie, které v mezičase zaplnily uvolněný prostor.

Přestože originál knihy Ponořme se do HTML5 vznikl již v roce 2011, věříme, že poskytne čtenáři dostatečný vhled jak do historie tohoto jazyka, tak do všech jeho podstatných vlastností. Zárukou je pro nás osobnost autora Marka Pilgrima, který je autorem i jiné knihy v naší edici, a to Ponořme se do Pythonu 3. Tato kniha je v Edici CZ.NIC jednou z nejoblíbenějších, a to zejména díky čtivému stylu, kterým autor čtenáře doslova vtáhne do popisovaného tématu. Autor, který v roce 2011 trochu tajemně zmizel z veřejného internetového prostoru, neustoupil ze svého originálního stylu ani v této knize.

Přeji Vám pěkné čtení.

Jaromír Talíř, CZ.NIC

Praha, 23. června 2015

Pět věcí, které byste měli vědět o HTML5

1. Není to jedna velká věc

Možná se ptáte: „Jak můžu začít používat HTML5, pokud ho nepodporují starší prohlížeče?“ Ale ta otázka je sama o sobě zavádějící. HTML5 není jedna veličina, ale soubor jednotlivých prvků. Nemůžete detekovat „podporu HTML5“, protože to by nedávalo žádný smysl. Můžete ale detekovat podporu jednotlivých prvků, jako jsou plátno, video nebo geolokace.

HTML si lze představovat jako tagy a špičaté závorky. Ty jsou jistě jeho důležitou součástí, ale není to všechno. Specifikace HTML5 také určují, jak tyto špičaté závorky fungují s JavaScriptem prostřednictvím Document Object Model (DOM). Není to tak, že by HTML5 pouze definoval tag <video>, ale v DOMu se nachází také odpovídající DOM API pro videoobjekty. Toto API můžete použít pro detekci podpory jednotlivých formátů videa, přehrání videa, jeho pozastavení, vypnutí zvuku, zjištění, kolik procent videa se stáhlo, a všeho dalšího, co potřebujete, abyste uživateli spolu s tagem <video> poskytli dostatečný komfort.

Kapitola 2 a Příloha A vás naučí jak správně detekovat podporu pro každý z nových prvků HTML5.

2. Nemusíte nic vyhazovat

Ať už ho milujete, nebo nenávidíte, nemůžete popřít, že HTML4 je nejúspěšnější značkovací formát všech dob. Na tomto úspěchu staví HTML5. Nemusíte vyhazovat už jednou napsané kódy, ani se nemusíte znova učit věci, které už znáte. Pokud vaše webové aplikace včera běžela v HTML4, bude běžet také dnes v HTML5. Opravdu.

Ovšem pokud chcete své webové aplikace vylepšit, jste tady správně. Uveďme si jeden příklad: HTML5 podporuje všechny formulářové prvky z HTML4, ale také obsahuje nové vstupní prvky. Mezi ně patří doplňky, na které jsme čekali už dlouho, jako posuvníky nebo prvky pro výběr data, zatímco jiné jsou méně nápadné. Například vstupní prvek typu email vypadá jako obyčejné textové pole, ale mobilní prohlížeče upraví klávesnici na displeji tak, aby se daly snadněji vkládat e-mailové adresy. Starší prohlížeče, které nepodporují vstupní prvek typu email, s tímto prvkem budou zacházet jako s klasickým textovým polem a formulář bude fungovat i nadále bez změny kódu nebo skriptování. To znamená, že můžete začít vylepšovat svůj web už dnes, i když budou někteří vaši návštěvníci stále ještě používat IE6.

Všechny šťavnaté detaily o formulářích HTML se dozvíte v kapitole 9.

3. Začít je snadné

„Upgradovat“ na HTML5 jde i pouhou změnou doctype. Doctype by měl být přítomen na prvním řádku kódu každé stránky HTML. Předchozí verze HTML definovaly velké množství doctype a vybrat si ten správný může být problematické. V HTML5 je pouze jediný doctype:

<!DOCTYPE html>

Upgradování na doctype HTML nerozbije váš stávající kód, protože zastaralé prvky, které předtím definovalo HTML 4, se budou zobrazovat i nadále v HTML5. Ale umožní vám to použít – a validovat – nové sémantické prvky, jako jsou <article>, <section>, <header> a <footer>. Všechno o těchto nových prvcích se dozvíte v kapitole 3.

4. Už to funguje

Ať už chcete něco vykreslit na canvasu, přehrát video, navrhnout lepší formuláře nebo vytvořit webové aplikace, které fungují i offline, zjistíte, že HTML5 má už teď velmi dobrou podporu. Firefox, Safari, Chrome, Opera a mobilní prohlížeče už teď podporují plátno (kapitola 4), video (kapitola 5) a geolokaci (kapitola 6), místní úložiště (kapitola 7) a další. Google již nyní podporuje anotaci pomocí mikrodat (kapitola 10). Dokonce Microsoft, který těžko může někdo osočovat z průkopnictví v oblasti podpory standardů, v Internet Exploreru 9 podporuje většinu prvků HTML5.

Každá kapitola této knihy obsahuje až příliš dobře známé tabulky kompatibility prohlížečů. Ale co je podstatnější, v každé kapitole najdete také otevřenou diskuzi o možnostech, které máte, když potřebujete podporu pro starší prohlížeče. Prvky HTML5 jako geolokace (kapitola 6) a video (kapitola 5) se poprvé objevily v podobě prohlížečových zásuvných modulů typu Gears nebo Flash. Další funkce, jako je plátno (kapitola 4), lze plně emulovat v JavaScriptu. Tato kniha vás naučí jak využívat nové funkce moderních prohlížečů, aniž byste zapomínali na prohlížeče starší.

5. Už tu s námi zůstane

Tim Berners-Lee vynalezl web na začátku devadesátých let. Později založil sdružení W3C, aby fungovalo jako strážce internetových standardů, což tato organizace dělá už déle než 15 let. V červenci roku 2009 sdružení W3C o budoucnosti internetových standardů řeklo následující:

Ředitel dnes oznámil, že až pracovní skupina XHTML 2 skončí podle plánu na konci roku 2009, nebude obnovena. Tímto krokem a navýšením zdrojů pro pracovní skupinu HTML chce W3C urychlit vývoj HTML5 a vyjasnit postoj organizace ohledně budoucnosti HTML.

HTML5 tu s námi už zůstane. Tak pojďme na to.

1. Jak jsme se sem dostali

1. Jak jsme se sem dostali

1.1 Začínáme

1.2 Typy MIME

1.3 Delší odbočka na téma tvoření standardů

1.4 Nepřerušená linie

1.5 Historie vývoje html mezi lety 1997 a 2004

1.6 Všechno, co víte o xhtml, je špatně

1.7 Konkurenční vize

1.8 Pracovní skupina what?

1.9 Zpátky k W3c

1.10 Postskriptum

1.11 K dalšímu čtení

1.1 Začínáme

Nedávno jsem narazil na něco, co řekl jeden z vývojářů Mozilly ohledně napětí, které nutně vzniká při tvoření standardů:

Implementace a specifikace spolu musejí jít ruku v ruce. Nechcete, aby implementace proběhla dřív, než jsou hotové specifikace, protože lidé začnou být závislí na detailech implementací, což omezuje specifikace. Také ovšem nechcete, aby byly specifikace hotové dřív, než vzniknou implementace a s nimi spojené zkušenosti, protože potřebujete zpětnou vazbu. Proto vzniká nevyhnutelné napětí, ale my se s ním zkrátka musíme nějak poprat.

Na tento citát myslete, když vám budu vysvětlovat, jak vzniklo HTML5.

1.2 Typy MIME

Tato kniha pojednává o HTML5, nikoliv o předchozích verzích HTML, ani o žádné verzi XHTML. Ale abychom pochopili historii HTML5 a důvody pro jeho vytvoření, musíme nejprve pochopit několik technických detailů. Konkrétně jsou to typy MIME.

Pokaždé, když váš webový prohlížeč vyšle požadavek na stránku předtím, než pošle skutečný zdrojový kód, posílá webový server tzv. hlavičku. Tyto hlavičky jsou obvykle neviditelné, ale existují nástroje pro tvorbu webových stránek, které je zviditelňují, pokud si to přejete. Ale tyto hlavičky jsou důležité, protože říkají vašemu prohlížeči, jak má interpretovat zdrojový kód stránky, který bude následovat. Nejdůležitější hlavička se jmenuje Content-Type a vypadá takto:

Content-Type: text/html

„text/html“ se nazývá „typ obsahu“ nebo „typ MIME“ stránky. Tato hlavička je jedinou věcí, která určuje, jak vypadá konkrétní zdroj a jak by měl být interpretován. Obrázky mají své vlastní typy MIME (image/jpeg pro formát JPEG, image/png pro formát PNG apod.). Soubory JavaScript mají své vlastní typy MIME stejně jako kaskádové styly. Své vlastní typy MIME má zkrátka úplně všechno. Celý Internet funguje na základě typů MIME.

Ve skutečnosti je to samozřejmě mnohem komplikovanější. První generace webových serverů (mluvím teď o serverech z roku 1993) nevysílala hlavičku Content-Type, protože ta tehdy ještě neexistovala (byla vymyšlena až v roce 1994). Z důvodů týkajících se kompatibility, které se datují až do roku 1993, budou některé oblíbené prohlížeče za určitých podmínek hlavičku Content-Type ignorovat (říká se tomu „content sniffing“, tedy „očichání obsahu“). Ale obvykle platí pravidlo, že všechno, co jste si kdy na webu prohlíželi – HTML stránky, obrázky, skripty, videa, dokumenty PDF, všechno s URL adresou – vám bylo naservírováno s konkrétním typem MIME v hlavičce Content-Type.

Zapište si to za uši, později se k tomu vrátíme.

1.3 Delší odbočka na téma tvoření standardů

Proč vlastně máme prvek <img>? To asi není otázka, kterou byste slyšeli každý den. Je jasné, že ho někdo musel vytvořit. Sám od sebe asi nevznikl. Každý prvek, každý atribut, každá funkce HTML je výtvorem někoho, kdo rozhodl, jak budou fungovat, a všechno to zapsal. Tito lidé nejsou bohové, ani nejsou dokonalí. Jsou to jen lidé. Chytří lidé, to ano, ale stále jen lidé.

Jedna ze skvělých věcí na standardech, které se vyvinuly „v otevřeném prostoru“ je, že se můžete vrátit v čase a na všechny takové otázky odpovědět. Diskuse se nacházejí v e-mailových konferencích, které jsou obvykle archivovány a dají se veřejně vyhledat. Proto jsem se rozhodl dát si trochu „e-mailové archeologie“, abych našel odpověď na otázku „Proč máme prvek <img>?“ Musel jsem se vrátit v čase do doby ještě předtím, než vznikla organizace nazvaná World Wide Web Consortium (W3C). Vrátil jsem se do internetového pravěku, kde jste mohli spočítat počet webových serverů na prstech obou rukou a možná ještě tak jedné nohy.

25. února roku 1993 Marc Andreessen napsal:

Rád bych navrhl nový volitelný tag HTML:

IMG

Povinným parametrem je SRC="url".

Tímto tagem se pojmenovává bitmapový nebo pixmapový soubor, který si pak prohlížeč pokusí ze sítě stáhnout, interpretovat ho jako obrázek a vložit ho do textu v místě výskytu tagu.

Příklad:

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

(Zavírací tag není potřeba, jedná se o samostatný tag.)

Tento tag může být zabudován do odkazu jako cokoliv jiného. V takovém případě se stane ikonou, která je citlivá na aktivaci stejně jako klasický textový odkaz.

Prohlížeče by měly mít volnost ohledně jimi podporovaných formátů obrázků. Bylo by například dobré, aby podporovaly Xbm a Xpm. Pokud prohlížeč nedokáže daný formát přečíst, může s ním místo toho udělat cokoliv chce (v X Mosaic vyskočí jako zástupný symbol výchozí bitmapa).

Tohle je požadovaná funkce pro X Mosaic. Funguje nám to a budeme to používat minimálně interně. Určitě se nebudu bránit nápadům, jak by se to mělo zvládnout v HTML. Pokud máte nějaký lepší nápad než to, co tu teď předkládám, dejte mi prosím vědět. Vím, že je to neurčité, pokud jde o formát obrázku, ale nevidím jinou alternativu než si říct „nechte prohlížeč dělat, co umí“ a počkat si na to, až někdo přijde s dokonalým řešením (MIME, snad jednou v budoucnu).

Xbm a Xpm byly oblíbené grafické formáty používané v operačním systému Unix.

„Mosaic“ byl jeden z nejstarších webových prohlížečů („X Mosaic“ byla jeho verze, která běžela pod Unixem). Marc Andreessen napsal tuto zprávu počátkem roku 1993, tedy ještě předtím, než založil firmu, která ho proslavila – „Mosaic Communications Corporation“ – a začal pracovat na vlajkové lodi této společnosti, „Mosaic Netscape“ (asi je znáte lépe pod jejich pozdějšími názvy „Netscape Corporation“ a „Netscape Navigator“).

„MIME, snad jednou v budoucnu“ je odkazem na vyjednávání obsahu (content negotiation), funkci http, kde klient (např. webový prohlížeč) sdělí serveru (např. webovému serveru), jaké typy zdrojů podporuje (např. image/jpeg), takže server může vrátit informaci ve formátu upřednostňovaném klientem. Původní protokol HTTP, tak jak byl definován v roce 1991 (jehož jediná verze byla realizována v únoru 1993), neumožňoval klientům žádným způsobem serverům sdělit, jaké grafické formáty podporují, a proto čelil Marc Andreessen takovému designovému dilematu.

O několik hodin později Tony Johnson odpověděl:

Mám něco hodně podobného v Midas 2.0 (ten používáme u nás v SLAC a chystáme se ho zveřejnit co nejdříve), ovšem všechny názvy se odlišují, a má to parametr navíc: NAME="name". A funguje to téměř úplně stejně jako tebou navržený tag IMG, např.:

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

Smyslem parametru name (název) je umožnit prohlížeči, aby měl sadu „zabudovaných“ obrázků. Pokud se název shoduje se „zabudovaným“ obrázkem, bude použit tento obrázek, aniž by bylo potřeba obrázek brát z vnějšího zdroje. Název by také mohl „line mode“ (textovým) prohlížečům napovědět, jaký symbol umístit namísto obrázku.

Je mi celkem jedno, jak se budou parametry a tagy jmenovat, ale bylo by rozumné, kdybychom používali totéž. Nejsem moc fanda zkratek, takže proč nepoužít IMAGE= a SOURCE=? Více se mi líbí ICON, protože to naznačuje, že by měl IMAGE být spíše menší, ale možná je ICON už příliš významově zatížené slovo?

Midas byl další ze starých webových prohlížečů, současník „X Mosaic“. Tento multiplatformní prohlížeč běžel pod Unixem a VMS. SLAC je zkratka pro Stanford Linear Accelerator Center, nyní SLAC National Accelerator Laboratory, centrum, které provozovalo první webový server ve Spojených státech (a zároveň první webový server mimo Evropu). Když Tony Johnson psal tuto zprávu, byl SLAC na poli WWW už zkušeným harcovníkem, jelikož na svém webovém serveru hostoval pět stránek po celých 441 dní.

Tony pokračoval:

Když už mluvíme o nových tazích, mám další, v některých ohledech podobný tag, pro který bych chtěl podporu v Midas 2.0. V zásadě jde o:

<INCLUDE HREF="...">

Záměrem je, aby byl druhý dokument obsažen v prvním dokumentu v místě, kde se vyskytuje tag. V zásadě může být odkazovaným dokumentem cokoliv, ale hlavním účelem je umožnit, aby byly do dokumentů vkládány obrázky (v tomto případě libovolně velké). S příchodem HTTP2 by se pak o formátu vkládaného dokumentu zvlášť jednalo.

„HTTP2“ je odkazem na Základní protokol HTTP, jak byl definován v roce 1992. V tomto okamžiku, tj. na počátku roku 1993, byl stále z větší části nezrealizován. Návrh známý jako „HTTP2“ byl dále vyvíjen a nakonec byl standardizován jako „HTTP 1.0“ (ovšem až za další tři roky). HTTP 1.0 už zahrnoval hlavičky požadavku pro vyjednání obsahu neboli „MIME, snad jednou v budoucnu.“

Tony pokračoval:

Jako alternativa mě napadlo:

<A HREF="..." INCLUDE>Zobrazit fotografii</A>

Příliš se mi nelíbí přidávat další funkce do tagu <A>, ale cílem je zde zachovat kompatibilitu i pro prohlížeče, které si neporadí s parametrem INCLUDE. Záměrem je, aby prohlížeče, které rozumí INCLUDE, nahradily text odkazu (v tomto případě „Zobrazit fotografii“) vloženým dokumentem (obrázkem), zatímco starší nebo „hloupější“ prohlížeče budou tag INCLUDE zcela ignorovat.

Tento návrh nebyl nikdy uskutečněn, ale myšlenka nahrazení obrázku textem, pokud obrázek chybí, je důležitou technikou pro zvýšení přístupnosti, která v Marcově původním návrhu <IMG> chyběla. O několik let později byla tato funkce přidána jako atribut <img alt>, což Nescape okamžitě pokazil tím, že s ním omylem zacházel jako s popiskem.

Za několik hodin poté, co Tony odeslal svou zprávu, odpověděl Tim Berners-Lee:

Představoval jsem si, že obrázky budou znázorněny jako:

<a name="fig1" href="fghjkdfghj" REL="EMBED, PRESENT">Obrázek</a>

kde relační hodnoty znamenají:

EMBED Vložte zde při předložení

PRESENT Předložte vždy, když je předložen zdrojový dokument

Vezměte na vědomí, že můžete použít různé kombinace těchto hodnot, a pokud prohlížeč nepodporuje žádný z nich, kód se nerozbije.

Chápu, že když se to použije jako metoda pro volitelné ikony, znamená to vkládání odkazů do sebe. Hmm. Ale speciální tag jsem nechtěl.

Tento návrh nebyl nikdy zrealizován, ale s atributem rel se můžeme setkat dodnes.

Jim Davis dodal:

Bylo by fajn, kdyby se dal nějak specifikovat typ obsahu, např.:

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

Ale jsem zcela ochoten se podřídit požadavku, abych určoval typ obsahu příponou souboru.

Ani tento návrh nebyl nikdy zrealizován, ale Netscape později přidal podporu vkládání mediálních objektů pomocí prvku <embed>.

Jay C. Weber se zeptal:

I když mému žebříčku typů médií, u kterých bych chtěl, aby je podporoval WWW prohlížeč, vévodí obrázky, nemyslím si, že bychom měli vymýšlet speciální techniky pro každé médium zvlášť. Co se stalo s nadšením pro používání mechanismu založeného na typech MIME?

Marc Andreessen odpověděl:

Toto není náhrada za blížící se používání MIME jako standardního dokumentového mechanismu. Jedná se o nezbytnou a jednoduchou implementaci funkce, která je potřebná nezávisle na MIME.

Jay C. Weber odpověděl:

Pojďme na chvíli zapomenout na MIME, aby nás to nepletlo. Moje námitka byla vedena proti diskuzi na téma „jak budeme podporovat vložené obrázky“ spíše než na téma „jak budeme podporovat vložené objekty v různých médiích“.

Jinak příští týden někdo přijde s návrhem na nový tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd"> pro audio.

Používat něco, co se dá uplatnit obecněji, by neměl být takový problém.

Když se ohlédneme nazpět, vypadá to, že Jayovy obavy byly zcela opodstatněné. Trvalo to o trochu víc než týden, ale HTML5 konečně přidalo nové prvky <video> a <audio>.

V odpovědi na Jayovu původní zprávu Dave Raggett řekl:

Přesně tak! Chci uvážit celou řadu možných typů obrázků/čárové grafiky, spolu s možností vyjednávání formátu. Timova poznámka o podpoře oblastí uvnitř obrázků s možností kliknutí je také důležitá.

O něco později v roce 1993 Dave Raggett navrhl HTML+ jako evoluci standardu HTML. Tento návrh nebyl nikdy realizován a byl překonán HTML 2.0. HTML 2.0 bylo „retrospektivní“, což znamená, že formalizovalo prvky, které se už v té době běžně používaly. „Tato specifikace spojuje, vyjasňuje a formalizuje řadu prvků, které zhruba odpovídají schopnostem HTML, jak se běžně používalo do června 1994.“

Dave později napsal HTML 3.0 založené na jeho předchozím návrhu HTML+. HTML 3.0 nebylo využito nikde kromě Areny, vlastního prohlížeče W3C, a bylo překonáno HTML 3.2, které bylo opět „retrospektivní“. „HTML 3.2 přidává prvky s širokou škálou využití, jako jsou tabulky, aplety a tok textu kolem obrázku, a zároveň poskytuje plnou zpětnou kompatibilitu s existujícím standardem HTML 2.0.“

Později se Dave stal spoluautorem HTML 4.0, vyvinul HTML Tidy a podílel se i na XHTML, XForms, MathML a dalších moderních specifikacích W3C.

Vraťme se do roku 1993, kdy Mark odpověděl Daveovi:

Možná bychom se vlastně měli zamyslet nad univerzálním procedurálním grafickým jazykem, ve kterém bychom mohli vkládat libovolné hypertextové odkazy připojené k ikonám, obrázkům nebo k textu, k čemukoliv. Má někdo představu, co v tomhle ohledu dokáže Intermedia?

Intermedia byl hypertextový projekt Brownovy univerzity. Byl vyvíjen mezi lety 1985 a 1991 a běžel pod A/UX, což byl operační systém podobný Unixu určený pro starší typy počítačů Macintosh.

Myšlenka „univerzálního procedurálního grafického jazyka“ se nakonec uchytila. Moderní prohlížeče podporují jak SVG (značkovací jazyk s vloženými skripty), tak <canvas> (procedurální grafický API s přímým vykonáváním instrukcí), ovšem <canvas> se původně objevil jako proprietární rozšíření, než se stal „retrospektivním“ díky WHATWG.

Bill Janssen odpověděl:

Další systémy, jimiž se můžeme inspirovat, které obsahují tento (celkem cenný) koncept, jsou Andrew a Slate. Andrew je postavený pomocí _insetů_, z nichž každý má nějaký zajímavý typ, jako je text, bitmapa, kresba, animace, zpráva, tabulka atd. Funguje zde koncept arbitrárního rekurzivního vkládání, takže jakýkoliv inset jakéhokoliv druhu může být vložen do jakéhokoliv jiného druhu, který podporuje vkládání. Například může být inset vložen do libovolného místa textu v textovém widgetu nebo do jakékoliv obdélníkové oblasti v kreslícím widgetu či do libovolné buňky v tabulce.

„Andrew“ odkazuje na Andrew User Interface System (v té době ovšem známý prostě jenom jako Andrew Project).

Mezitím dostal Thomas Fine jiný nápad:

Podle mě je nejlepším způsobem, jak zacházet s obrázky ve WWW, používání MIME. Jsem si jistý, že postscript je už v tuto chvíli v MIME podporovaný podtyp, a právě on si dokáže velmi dobře poradit s mícháním textu a grafiky.

Namítáte, že se na něj nedá klikat? Ano, máte pravdu. Myslím, že s tímhle si už teď dokáže poradit display poscript. A i kdyby náhodou ne, tak doplnění standardního postscriptu je jednoduchá záležitost. Definujte příkaz s odkazem, který specifikuje URL, a použije současnou cestu jako uzavřenou oblast pro tlačítko. Jelikož to postscript tak dobře umí s cestami, budou libovolné tvary tlačítka brnkačka.

Display Postscript byla zobrazovací technologie pro obrazovkové servery, na jejímž vývoji se podílely firmy Adobe a NeXT.

Tento návrh nebyl nikdy zrealizován, ale myšlenka, že nejlepším způsobem jak vylepšit HTML je nahradit ho něčím úplně jiným, se stále čas od času objevuje.

Tim Berners-Lee, 2. března 1993:

HTTP2 umožňuje dokumentu, aby obsahoval jakýkoliv typ, o kterém uživatel řekl, že ho zvládne, a nikoliv pouze registrované typy MIME. Proto můžeme experimentovat. Ano, myslím, že existuje dost argumentů pro spojení postscriptu s hypertextem. Nevím, zda stačí Display Postcsript. Vím, že se Adobe snaží vytvořit svoje vlastní na postcriptu založené „PDF“, které bude čitelné v jejich vlastním druhu prohlížecích programů.

Myslel jsem, že obecný zastřešovací jazyk pro odkazy (založený na Hytime?) by umožnil standardům pro hypertext a grafiku/video se vyvíjet samostatně, což by pomohlo obojímu.

Místo tagu IMG použijme INCLUDE a nechme ho odkazovat k libovolnému typu dokumentu. Nebo použijme EMBED, pokud INCLUDE zní jako příkaz v C++, od kterého by lidé čekali, že poskytne zdrojový kód SGML, aby byl analyzován inline – což rozhodně nebyl záměr.

HyTime byl raný, na SGML založený hypertextový dokumentový systém. Často se přetřásal v časných diskuzích na téma HTML a později XML.

Timův návrh na tag <INCLUDE> nebyl nikdy realizován, i když jeho ozvěny můžeme zaznamenat v prvcích <object>, <embed> a <iframe>.

Konečně 12. března 1993 se Marc Andreessen vrátil k tomuto diskuznímu vláknu:

Zpátky k vláknu o vkládání obrázků – už brzo vydám Mosaic v 0.10, která bude podporovat vkládání GIFů a XMB obrázků/bitmap, jak jsem psal dříve. (…)

V tuto chvíli nejsme připraveni na podporu INCLUDE/EMBED. (…) Takže nejspíš použijeme <IMG SRC="url"> (nikoliv ICON, protože ne všechny vkládané obrázky je tak možné nazývat). Prozatím u vkládaných obrázků nebude uveden content-type; do budoucna plánujeme jeho podporu (spolu s obecným přijetím MIME). Rutiny pro čtení obrázků, které teď používáme, ve skutečnosti dokážou poznat formát obrázku za pochodu, takže na příponě souboru nezáleží.

1.4 Nepřerušená linie

Všechny aspekty této téměř 19 let staré konverzace vedoucí ke vzniku prvku HTML, který se používá snad na každé webové stránce, jež kdy byla vytvořena, mě nesmírně fascinují. Uvažte následující:

• Protokol HTTP stále existuje. HTTP se úspěšně vyvinul z 0.9 do 1.0 a později 1.1. A vyvíjí se dál.

• HTML stále existuje. Ten primitivní datový formát – který ani nepodporoval vložené obrázky! – se úspěšně vyvinul do verzí 2.0, 3.2, 4.0. HTML tvoří nepřerušenou linii. Určitě je to linie pokroucená, zauzlovaná a zasukovaná. Na vývojovém stromě HTML bylo spousta „uschlých ratolestí“, míst, kde se lidé, kteří měli standardy na starosti, příliš rozjeli (a to na úkor autorů a realizátorů). Ale i přesto. Jsme v roce 2012 a webové stránky z roku 1990 se stále zobrazují v moderních prohlížečích. Právě jsem jednu načetl ve svém nejnovějším mobilu s Androidem, a ani mi přitom nevyskočilo upozornění „prosím čekejte, než se převede historický formát…“.

• HTML bylo vždy konverzací mezi tvůrci prohlížečů, autory stránek, tvůrci standardů a dalšími lidmi, kteří se vynořili bůhví odkud, aby si povídali o špičatých závorkách. Většina úspěšných verzí HTML byla „retrospektivní“ – doháněla technický svět, a přitom se ho snažila pošoupnout správným směrem. Každý, kdo vám říká, že by mělo HTML zůstat „čisté“ (nejspíš ignorováním tvůrců prohlížečů nebo ignorováním autorů, případně obojím), je jednoduše vedle. HTML nebylo nikdy čisté, a všechny pokusy ho očistit byly natolik katastrofální, že se jim vyrovnaly pouze pokusy HTML něčím nahradit.

• Žádný z prohlížečů z roku 1993 neexistuje v podobě, v jaké bychom ho mohli poznat. Nestcape Navigator byl opuštěn v roce 1998 a od základů přepsán, aby vznikla Mozilla Suite, od které se pak odtrhl Firefox. Internet Explorer si prošel skromnými začátky v „Microsoft Plus! pro Windows 95“, kde se ocitl v jednom balíčku s motivy plochy a pinballem. (Ale samozřejmě po jeho stopách můžeme pátrat také v ještě vzdálenější minulosti.)

• Některé z operačních systémů z roku 1993 stále existují, ale žádné z nich nemají vztah k modernímu Internetu. Většina lidí, kteří chodí na web, k tomu využívají PC s operačním systémem Windows 2000 nebo s pozdější verzí, Mac s Mac OS X, PC s určitou odnoží Linuxu nebo kapesní zařízení jako iPhone. V roce 1993 Windows běžel pod verzí 3.1 (a soutěžil s OS/2), Macy používaly System 7 a Linux se šířil přes Usenet. (Chcete si užít trochu legrace? Najděte nějakého veterána a pošeptejte mu „Trumpet Winsock“ nebo „MackPPP.“)

• Někteří z těchto lidí stále pracují v oboru a podílejí se na tom, čemu teď říkáme jednoduše „webové standardy“. A to i po téměř 20 letech. A někteří z nich se podíleli už na předchůdcích HTML, s datací do 80. let i dříve.

• Když je řeč o předchůdcích… Díky výsledné popularitě HTML a webu je snadné zapomínat na další tehdejší formáty a systémy, které ovlivnily jejich výslednou podobu. Andrew? Intermedia? HyTime? HyTime přitom nebyl žádný obskurní akademický projekt – byla to norma ISO. Schválili ho pro vojenské použití. Zkrátka důležitá záležitost. Ostatně si o něm můžete přečíst sami… na téhle stránce, HTML ve svém webovém prohlížeči[1].

Ale nic z toho neodpovídá na původní otázku: proč máme prvek <img>? Proč ne prvek <icon>? Nebo prvek <include>? Proč nemáme hypertextový odkaz s atributem <include> nebo nějakou kombinaci hodnot rel? Proč zrovna prvek <img>? Docela jednoduše proto, že Marc Andreessen svůj kód oficiálně vydal, a vydané kódy vyhrávají.

To samozřejmě neznamená, že všechny vydané kódy vyhrávají; Andrew, Intermedia a HyTime své kódy přece také vydaly. Kód je nezbytnou podmínkou pro úspěch, ale sám o sobě nestačí. A už vůbec nechci říct, že vydání kódu před vznikem standardu je nejlepší řešení. Marcův prvek <img> nestanovil společný grafický formát, neurčoval, jak bude kolem něho proudit text, a nepodporoval textové alternativy ani nouzový obsah pro starší prohlížeče. A o sedmnáct let později stále ještě bojujeme s očicháváním obsahu a je to stále zdrojem neuvěřitelných bezpečnostních děr. A tohle všechno můžete vysledovat do doby před 17 lety, napříč velkými válkami prohlížečů, k 25. únoru 1993, kdy Marc Andreessen jen tak mimoděk prohodil „MIME, snad jednou v budoucnu,“ a pak svůj kód stejně vydal.

Ti, kdo vyhrávají, jsou ti, kdo vydávají.

1.5 Historie vývoje html mezi lety 1997 a 2004

V prosinci 1997 vydalo sdružení World Wide Web Consortium (W3C) HTML 4.0 a okamžitě ukončilo pracovní skupinu HTML. Ani ne o dva měsíce později jiná pracovní skupina W3C vydala XML 1.0. Pouhé tři měsíce nato provozovatelé W3C uspořádali workshop na téma „Utváření budoucnosti HTML“, aby odpověděli na otázku: „Vykašlala se W3C na HTML?“

Tohle byla jejich odpověď:

Diskuze dospěly k názoru, že další rozšiřování HTML 4.0 by bylo obtížné stejně jako převod 4.0 na aplikaci XML. Navrhovaný způsob, jak se lze vypořádat s těmito omezeními, je začít znovu s novou generací HTML založenou na balíku sad tagů XML.

Sdružení W3C obnovilo pracovní skupinu HTML a pověřilo ji vytvořením tohoto „balíku sad tagů XML“. Prvním krokem byl v prosinci roku 1998 návrh prozatímní specifikace, která jednoduše převedla HTML do XML bez přidávání nových prvků či atributů. Tato specifikace se později stala známou pod názvem „XHTML 1.0“. Definovala nový typ MIME pro dokumenty XHTML application/xhtml+xml. Pro usnadnění přechodu pro existující stránky HTML4 byl také zahrnut Dodatek C, který „shrnuje pokyny pro tvorbu stránek pro autory, kteří chtějí, aby se jejich dokumenty XHTML zobrazovaly v existujících uživatelských agentech HTML.“ Dodatek C říkal, že jste mohli tvořit takzvané „XHTML stránky“, ale vydávat je přitom s typem MIME text/html.

Jejich dalším cílem byly webové formuláře. V roce 1999 tatáž pracovní skupina HTML vydala první návrh „Rozšířených formulářů XHTML“. Svá očekávání popsala v prvním odstavci:

Po pečlivém zvážení se pracovní skupina HTML rozhodla, že cíle pro další generaci formulářů jsou neslučitelné se zachováním zpětné kompatibility s prohlížeči vytvořenými pro dřívější verze HTML. Naším cílem je vytvořit nový čistý model formuláře („Rozšířené formuláře XHTML“) založený na jasně definovaných požadavcích. Požadavky popsané v tomto dokumentu se zakládají na zkušenostech s celou škálou formulářových aplikací.

O několik měsíců později byly „Rozšířené formuláře XHTML“ přejmenovány na „XForms“ a dostaly svoji vlastní pracovní skupinu. Tato skupina pracovala paralelně s pracovní skupinou HTML a konečně vydala první verzi XForms 1.0 v říjnu 2003.

Mezitím se po dokončení přechodu na XML pracovní skupina HTML zaměřila na vytvoření „nové generace HTML“. V květnu 2001 vydali první verzi XHTML 1.1, která přidávala k XHTML jen několik málo prvků navíc, ale také rušila zadní vrátka v Dodatku C. Od verze 1.1 měly všechny dokumenty XHTML obsahovat typ MIME application/xhtml+xml.

1.6 Všechno, co víte o xhtml, je špatně

Proč jsou typy MIME důležité? Proč se k nim neustále vracím? Jen tři slova: „draconian error handling“, tj. přísné zacházení s chybami. Prohlížeče se vůči HTML vždycky chovaly benevolentně. Pokud vytvoříte HTML stránku a zapomenete na tag </head>, prohlížeče stránku i přesto zobrazí. (Některé tagy implicitně vyvolají konec <head> a začátek <body>.) Tagy byste měli uzavírat hierarchicky, to znamená od posledního k prvnímu, ale když napíšete kód ve stylu <b><i></b></i>, prohlížeče si s tím (nějak) poradí a zobrazí stránku bez chybového hlášení.

Jak se dá očekávat, skutečnost, že „vadné“ HTML stránky v prohlížečích fungovaly, vedla autory k vytváření vadných HTML stránek. Velké spousty vadných stránek. Podle některých odhadů má až 99 % všech HTML stránek na Internetu alespoň jednu chybu. Ale protože na tyto chyby prohlížeče nevyhazují žádná viditelná chybová hlášení, nikdo je nikdy neopraví.

W3C tohle vnímalo jako základní problém Internetu a rozhodlo se to napravit. XML vydané v roce 1997 porušilo tradici benevolentních klientů, když stanovilo podmínku, že všechny programy, které konzumují XML, musí zacházet s tzv. „well-formedness“ chybami (chyby nesprávně strukturovaného kódu) jako s fatálními. Konceptu selhání u první chyby se začalo říkat „drakonické trestání chyb“ podle starořeckého státníka Drakóna, který zavedl trest smrti i za relativně mírné porušení jeho zákonů. Když v W3C přeformulovali HTML jako slovník XML, zavedli podmínku, že všechny dokumenty vytvářené s novým typem MIME application/xhtml+xml budou podléhat drakonickému trestání chyb. Pokud by vaše XHTML stránka obsahovala byť jen jednu chybu v struktuře kódu – např. opomenutí tagu </head> nebo uzavírání tagů ve špatném pořadí – nebudou mít webové prohlížeče jinou možnost než přestat stránku zpracovávat a zobrazit koncovému uživateli chybové hlášení.

1.7 Konkurenční vize

Následujících sedm principů představuje podle nás nejdůležitější požadavky pro tuto práci.

Zpětná kompatibilita, volná cesta k přechodu

Dobře definované zacházení s chybami

Uživatelé by neměli být vystaveni chybám autorů

Praktické využití

1.8 Pracovní skupina what?

1.9 Zpátky k W3c

1.10 Postskriptum

1.11 K dalšímu čtení