Rozhovor se uskutečnil letos v únoru, tedy pár týdnů před tím, než W3C založilo pracovní skupinu pro HTML. Z tohoto důvodu se v rozhovoru o nové skupině u W3C nehovoří.
O (X)HTML5
Specifikace Web Application 1.0, častěji označovaná jako (X)HTML5, je novou verzí HTML, která soupeří o místo nástupce HTML4 a XHTML1. Specifikaci (X)HTML5 připravuje skupina Web Hypertext Application Technology Working Group (více o WHATWG se můžete dočíst na Lupě v článcích WHATWG – budoucnost webu? a Webové aplikace podle WHATWG).
O Ianu Hicksonovi
Ian Hickson ví o webu a webových technologiích tolik jako málokdo jiný. S tím, jak webové prohlížeče fungují uvnitř, se Ian seznámil, když pracoval pro Opera Software, a když ve svém volném čase ověřoval chyby v Bugzille projektu Mozilla. Ačkoliv má pracovní rozvrh plně nabitý, na mnoha fórech a diskusních skupinách zaměřujících se na webové technologie najdete Ianovy odpovědi (vystupuje pod přezdívkou „Hixie“). Dnes Ian pracuje pro Google, kde v roce 2005 zpracoval vyčerpávající analýzu o tom, jak jsou na webu používány značkovací jazyky. V roce 2007 je Ian editorem specifikace (X)HTML5 a členem pracovní skupiny pro CSS u W3C.
Rozhovor
Proč potřebujeme (X)HTML5? A kdy začala být tato potřeba zjevná?
Na začátku bylo HTML jazykem určeným pro vědce, kteří pomocí něj mohli sdílet své dokumenty. Časem se vyvinulo. Přidala se například značka img, formuláře, WYSIWYG vlastnosti, které se později opět odebraly ve prospěch CSS atd. Během posledních let se web vyvíjel dál a je dynamičtější než kdy předtím (někteří to nazývají „Web 2.0“). Snahou HTML5 je udržet a nadále vyvíjet HTML, aby vyhovovalo potřebám autorů 21. století.
(X)HTML5 je nyní pracovní návrh. Jaký je předpokládaný časový plán postupu (X)HTML5 skrze standardizační proces k finálnímu doporučení?
U HTML5 zkoušíme nový model, ve kterém jsou některé části specifikace považovány za dokončené dříve než ty ostatní. Některé sekce jsou totiž vyzrálé, s řadou implementací, testů a aktivně se používají, zatímco jiné jsou relativně nové a ve stádiu příprav.
Zatím to není zřejmé, ale členové naší komunity připravují systém, který bude opatřovat specifikaci poznámkami, takže uvidíte, které části již jsou stabilní a které nikoliv. Další členové komunity připravili stránku, na které si můžete vybrat, jaké změny specifikace si přejete zobrazit, takže si můžete například prohlédnout pouze změny ve stabilních částech specifikace, které ovlivňují Firefox.
Je proto těžké dát přesný časový odhad. Některé části specifikace jsou již hotovy a aktivně se používají, např. Yahoo! Pipes používá prvek canvas z HTML5. Podíváme-li se do historie, tak mez, kdy specifikace byly označeny za finální doporučení, nebyla pevně dána. Například takové HTML4, které se stalo doporučením na konci devadesátých let, se stále vyvíjí a opravuje. V prohlížečích nejsou implementovány všechny části HTML4, o některých částech HTML4 je známo, že jsou špatné, ale neexistuje žádný přehled chyb atd. Velká část práce na HTML5 je v podstatě opravou chyb HTML4.
Mimochodem, HTML5 je vyvíjen zcela otevřeně. Kdokoliv se může přidat. Podívejte se na www.whatwg.org, kde naleznete odkazy na naše fórum, IRC kanál, blog, FAQ, wiki, mailové skupiny atd.
(X)HTML5 přichází s novými elementy jako jsou je sekce, rozšíření elementu input, rozhovor, způsob vyznačování obrázků a mnohé další. Můžeš nám krátce popsat nové elementy a důvody, proč byly zahrnuty?
Při vývoji HTML5 se snažíme o vědecký přístup více, než bývá u nových specifikací obvyklé. Takže například řada nových značek pro sekce (na vyznačení bloků s navigací, článků, sekcí, patiček, hlaviček atd.) je založena na studii několika miliard dokumentů realizovanou společností Google, díky které jsme zjistili, že právě tyto sekce jsou autory nejvíce používané.
Další vlastnost – cílené styly (scoped stylesheet)- umožňuje do dokumentu vložit kaskádové styly společně s novým obsahem tak, že se jednotlivá pravidla aplikují pouze na tento vložený obsah. Tuto vlastnost jsme přidali na základě odezvy autorů.
Ve skutečnosti jsou všechny části specifikace předmětem odezvy ze strany webdesignerů a tvůrců webových prohlížečů. Jelikož dobře víme, že bez zájmu obou těchto skupin bude specifikace k ničemu, věnujeme hodně úsilí na shromažďování jejich názorů.
Jednou z dalších připravovaných vlastností je datagrid. Jedná se o prvek pro zobrazování stromů a seznamů se zabudovanou podporou AJAXového načítání dat. Pomocí něj můžete podobně jako klasický webmail zobrazit několik z tisíců vašich e-mailů, ale místo zobrazení 20 z nich najednou, můžete scrollovat mezi všemi. Stáhnou se teprve, až budou zapotřebí.
Máme API pro ukládání dat na klientovi (client-side storage), myslím že již nyní implementované Firefoxem. Dále indikaci režimu offline, takže můžete psát aplikace, které poznají přechod do offline režimu. Máme API pro drag & drop, které je kompatibilní s implementací v IE a Safari, API pro bezpečnou komunikaci mezi doménami i mezi rámci a API pro obousměrnou komunikaci klient-server. Pochopitelně nevíme, které z nich se ujmou, některé přidané vlastnosti jsme ostatně opět odstranili, protože nebyly dostatečně významné.
Jeden z největších problému HTML je, že autoři mohou tvořit dokumenty s neukončenými nebo překrývajícími se značkami, tzv. tag soup.
A je to skutečně problém? Nebo to je důvod, proč web je tak úspěšný? Ubíral by se web stejným směrem, když by fungoval stejně jako většina dalších systémů zobrazujících chybové hlášení, kdykoliv je cokoliv jen trochu špatně?
Řada autorů nepíše dokumenty podle specifikace právě proto, že může vytvářet „tag soup“. A když kód není podle specifikace, nemusí se správně aplikovat kaskádové styly, nemusí proběhnout JavaScript a některé prohlížeče nemusí být schopny zpracovat obsah tak, jak jeho autor zamýšlel.
Přísné zacházení s chybami, tzv. draconian error handling – termín, který používáme pro nepovolené chyby namísto tichého zotavení se, jako to dělá HTML, není jediné řešení zajištující konzistentní chování prohlížečů. U HTML5 jsme šli cestou definování, co každý dokument znamená, dokonce i když není validní, až do posledního detailu, takže každý prohlížeč bude dokument zpracovávat stejně, ať již je dokument validní nebo není. (Jedná se o stejnou techniku, jakou používají CSS.)
Proč nezarazit psaní „tag soup“ požadavkem, aby prohlížeče akceptovaly pouze dokumenty napsané dle specifikace?
Na webu již existují tucty, ne-li stovky miliard dokumentů. U Google jsem dělal studii testovací implementace parseru napsaného podle HTML5 specifikace na vzorku několika miliard dokumentů. Dle střízlivého odhadu z nich více než 78 % obsahuje chyby. Po troše experimentování, kdy jsem bral v úvahu větší množství chyb, vyšlo číslo 93 %. A to se jedná pouze o základní syntaktické chyby – nepočítám špatné používání HTML, jako je např. umístění elementu p do ol.
Pokud bychom po prohlížečích chtěli ignorovat takové dokumenty, nemohli bychom prohlížet 90 % webu.
Uvažte, pokud by jeden prohlížeč zobrazoval chybové zprávy na polovině webu a jiný prohlížeč by žádné chyby nezobrazoval a místo toho vykresloval web přibližně tak, jak autor zamýšlel. Který z nich bude běžný člověk používat?
Pokud chceme, aby HTML5 bylo úspěšné, musí se o něj výrobci prohlížečů zajímat. Jakékoliv požadavky, které by snížily jejich tržní podíl oproti prohlížečům, které by je neimplementovaly, budou ignorovány.
(X)HTML5 obsahuje mechanismus pro rozšiřování sémantiky existujících elementů používáním předdefinovaných názvů atributu class. Předdefinované názvy tříd mohou být tou nejkontroverznější částí (X)HTML5, protože přetěžují atribut class. XHTML2 poskytuje podobnou funkcionalitu pomocí atributu role. Který přístup je lepší a proč?
Návrh použít předdefinované názvy tříd je zatím jen ve stádiu úvah. Čekáme na zpětnou vazbu od autorů a implementátorů, zda je přijatelný. Jeho specifikace v současné době obsahuje řadu nezodpovězených otázek (např. co se stane když dvě třídy na elementu mají protikladný význam), takže není v žádném případě dokončený.
U atributu role jsem nebyl schopen rozluštit, co dělá, a jak by měl být implementován. Má svou specifikaci, ale ta je ve skutečnosti nejasná. Nemohu ho tedy komentovat.
Element font je příšerný vynález, zejména protože autoři používající nástroje pro tvorbu obsahu využívají element font místo sémantických značek. Specifikace (X)HTML5 podporuje element font v případě, že byl obsah vytvořen WYSIWYG editorem. Jaký je pro to důvod? Proč dostaly WYSIWYG editory výjimku? Nestane se web na základě této výjimky méně přístupný?
Podobně jako předtím, element font a WYSIWYG sekce jsou ve stádiu úvah, stávající text není hotový. Ale dostali jsme již dostatečnou pozitivní odezvu, kterou musíme vzít v úvahu.
Hlavní důvod, proč by WYSIWYG editory měly dostat výjimku, je, že dnešní uživatelská rozhraní neznají dobré řešení sémantických editorů pro obyčejné uživatele. Mohli bychom to po editorech požadovat, ale protože nikdo neví, jak to udělat, byl by to hloupý požadavek. Opět musíme udělat kompromis mezi dokonalostí, potřebami a omezeními reálného světa.
Je to, že je tak těžké vytvořit nástroje jako jsou WYSIWYG editory, které generují správný sémantický kód a mohou být snadno používány netechnicky založenými lidmi, problémem HTML?
Ne, domnívám se, že je to složité samo o sobě. Lidé přemýšlí vizuálně. Chtít po webdesignerovi, aby přemýšlel v pojmech (např.) hlavička místo ve velikostech fontů je něco, co tvůrci WYSIWYG nástrojů a badatelé v oblasti uživatelského rozhraní dosud nevyřešili. Osobně nemyslím, že je to ztracený případ, prostě jsme se tak daleko ještě nedostali.
Velké množství obsahu webu je vytvořeno právě editačními nástroji. Bude vůbec někdy web sémanticky bohatý a přístupný?
Vždycky tu budeme mít kontinuum webů, od těch nepoužitelných po ty dobře přístupné. Podobně jako ve všech oblastech lidského snažení tu vždy budou schopní webdesigneři, kteří rozumí základům tvorby webů nezávislých na zobrazovacím zařízení, zohledňující všechny druhy uživatelů a zároveň tu vždy budou nezkušení a neznalí webdesigneři, kteří uvažují pouze na základě své osobní zkušenosti s konkrétním prohlížečem na konkrétním počítači bez ohledu na zkušenost dalších potenciálních uživatelů.
Nepochybně to nejlepší, co můžeme udělat, je navrhnout jazyk tak, aby dělal „ty správné věci“ snadněji a investovat mnohem více do vzdělávání. V tomto ohledu je HTML na stejné lodi jako mnohem důležitější předměty. Myslím, že jakmile zvýšíme kvalitu vzdělanosti obecně, zlepší se i porozumění pro důležitost přístupnosti apod.
Specifikace XHTML5 říká, že „obecně řečeno autoři jsou odrazování od používáni XML na webu“. Proč tedy píšete XML specifikaci jakou je XHTML5 a následně odrazujete autory od jejího používání? Proč prostě podporu XML (tedy XHTML5) nezahodit?
Někteří lidé budou XML s HTML5 používat, ať už uděláme cokoliv. Je to jednoduché: XML je metajazyk pro popis stromových struktur, HTML5 je stromová struktura, takže je jasné, že XML může být použito pro popis HTML5. Problém by byl, pokud bychom to nespecifikovali. Pak by to každý, kdo by si řekl, že je to samozřejmé, udělal mírně odlišným způsobem a měli bychom tu noční můru interoperability. Proto to raději překousneme a definujeme, jak to má fungovat, pokud to lidé použijí.
Předseda pracovní skupiny pro HTML u W3C, Steven Pemberton, řekl „HTML je bordel!“ a „spíše než aby byl navrhován, HTML si prostě roste, jak do něj rozliční lidé přidávají nové věci.“
Tak to má pravdu. A stále to pokračuje. Snažíme se ale vnést do celého procesu trochu rozumu.
Když je tedy HTML špatně navrženo, proč má cenu ho uchovávat? Nebo je HTML opravitelné? Pokud ano, jak ho (X)HTML5 opraví?
Původní důvod, proč jsem se do této práce zapojil, bylo, když jsem si uvědomil, že lidská rasa napsala doslova miliardy elektronických dokumentů, ale bez toho aby řekla, jak mají být zpracovávány. Pokud by za tisíc let někdo nalezl „poklad“ plný HTML dokumentů a rozhodl se vytvořit HTML prohlížeč, který by mu je zobrazil, nedokázal by to udělat! Dokonce ani s existujícími specifikacemi HTML4, SGML, DOM2 HTML apod. Jejich dokonalá implementace totiž nedokáže naprostou většinu dokumentů zobrazit tak, jak jejich autoři zamýšleli.
Všichni velcí výrobci prohlížečů dnes vkládají alespoň polovinu svých zdrojů přidělených na vývoj prohlížeče do reverzního inženýrství ostatních prohlížečů, aby zjistili, jak věci mají fungovat. Pokud si vezmete např.
<p> <b> Hello <i> Cruel </b> World! </i> </p>
…a spustíte nějaký JavaScript na tomto kódu, který má zobrazit obsažené elementy a jejich rodiče, co se stane? Ukazuje se, že před HTML5 tu nebyla žádná specifikace, která by toto chování definovala.
Rozhodl jsem se, že už kvůli budoucím generacím bychom měli přesně zdokumentovat, jak zpracovávat dnešní dokumenty, aby až se budou tyto generace dívat zpět, mohly znovu vytvořit HTML prohlížeče a získat zpět naše data, a to i v případě, že nebudou mít k dispozici zdrojové kódy Microsoft Internet Exploreru. (Jelikož je IE proprietární, je nepravděpodobné, že jeho zdrojový kód přežije daleko do budoucnosti. Můžeme mít více štěstí s některým z dalších prohlížečů, jehož zdrojové kódy jsou více nebo méně zdarma dostupné).
Jakmile jsem ale začal dokumentovat HTML kvůli budoucnosti, napadlo mě, že tato snaha může mít výhody již dnes, například dnešní výrobci prohlížečů by byli schopní použít jednu specifikaci místo toho, aby podnikali reverzní-inženýrství jeden na druhém; a že bychom mohli autorům přidat nové funkce.
Zastánci (X)HTML5 nazývají XHTML2 radikálním. Historie ukázala, že technologické změny jsou sice často kontroverzní, ale nakonec jsou tou nejlepší volbou. Např. v posledních 40 letech se technologie pro šíření hudby radikálně změnila z gramofonových desek na kazety, na CD, na čistě digitální. Proč by se měl web vyhýbat radikální technologické změně?
Když se podíváme na hudbu, najdeme několik klíčových faktorů. Přechod z gramofonových desek na kazety přišel s výraznou výhodou, jakou je odolnost vůči otřesům a přepisovatelné médium. A také si všimněte, že kazety gramofonové desky nenahradily, existovaly po dlouhou dobu pro různé posluchače společně. Představení digitálních optických médií (CD) také přineslo radikální výhody: výrazné zvýšení kvality a bezztrátové kopírování. Gramofonové desky byly nahrazeny CD, protože nabízely stejnou věc, ale lépe. Nicméně kazety se používaly ještě řadu let, jelikož přepisovatelná CD nebyla na začátku široce dostupná. Dnes sledujeme přechod od sbírek CD na digitální magnetická média (např. iPody), ale při pozorném pohledu naleznete jasnou migrační cestu od audio CD a kazet na přenosné přehrávače: CD mohou být rippována a uložena na nová média a tato nová média mohou hrát v magnetofonových přehrávačích v autech stejně jako původní kazety.
Takže vidíme, že úspěšná radikální změna vyžaduje dvě klíčové vlastnosti:
- zásadní výhody, které vyváží bolestný přechod
- zpětnou kompatibilitu s původní technologií
Jsem si jistý, že přijde den, kdy tu budou nové technologie, které posunou web do nového světa, ale nemyslím, že jsou v dohledu.
Svým způsobem je samo HTML5 zásadní změnou. Ani ne pro to, co specifikuje, ale jakým způsobem bylo vytvořeno. Je to první skutečně otevřená, spolupracující komunita, která se chopila tak významného úkolu (ne menšího než přepsání knihy o základním jazyku webu) – doufejme, že příští technologie budou tento model následovat, místo obvyklejšího přístupu „za zavřenými dveřmi“, který používá řada jiných technologií.
Podle představ většiny lidí je HTML mrtvé a (X)HTML5 je vnímáno jako pokus o jeho vzkříšení. Jak chcete za této představy uspět v marketingu HTML u spotřebitelů (těch, kdo weby vytváří)?
Podle jednoho z našich dalších výzkumů, který jsme pro HTML5 podnikli, je více než 95 % současného webu HTML. Ten zbytek jsou převážně kupy PDF dokumentů, Wordovských dokumentů a plain textu. Podle jaké definice slova „mrtvé“ může být HTML považováno za mrtvé? Webdesigneři nikdy nepřestali psát HTML stránky. Nemyslím si, že budeme mít sebemenší problém v přesvědčování, aby tak činili i nadále.
Převzato se svolením z xhtml.com.
Původní text: xhtml.com/en/future/conversation-with-x-html-5-team/
Překlad: Martin Hassman
