ARIA v HTML5 na Standards Suck

Na nově založeném blogu Standards Suck (pěkný název pro blog) najdete video ARIA in HTML5, ve kterém Anne van Kesteren vysvětluje, co je to ARIA (Accessible Rich Interactive Applications) a o řešení její syntaxe pro HTML5.

BTW provokativní nápis "Standards Suck" najdete i na Annově blogu. Ačkoliv první dojem může svádět, nejedná se určitě o kritiku existence či zbytečnosti webových standardů. Anne je členem několika pracovních skupin W3C a editorem několika menších specifikací, a tráví tím jistě i nemalou část svého volného času na to, aby popíral smysl svého konání.

Cítím v tom spíš povzdech nad tím, že svět webových standardů často nefunguje, jak bychom si přáli (ať již na rovině teoretické nebo té implementační) a neexistuje cesta, jak z toho snadno ven.

V tomto ohledu se musím připojit. Ano, standards suck, bohužel. Můj obdiv mají všichni, kdo se snaží o změnu.

Já si každopádně dávám http://standardssuck.org do své čtečky a jsem zvědav, co dalšího se tam objeví.

Jak na našeptávač s HTML5

Je to pár let, co se objevil Google Suggest, nedlouho poté ho následovaly české portály se svými Našeptávači a Rádci. Princip je jednoduchý, ale ne každý chce našeptávač vytvářet na zelené louce (ten od Seznamu se blíží k 300 řádkům a dokonce padlo obvinění, že české portály od sebe kód opsaly).

Pojďme se podívat, nakolik se nám zmíněných 300 řádků kódu zkrátí v případě, že prohlížeč bude podporovat HTML5. Anne van Kesteren tvorbu našeptávače podrobně popisuje v návodu An HTML5-style "Google Suggest".

My si zobrazíme rovnou výsledek. Klientskou část našeptávače v HTML5 lze napsat na 4 řádky (a to se kód zalamuje, jinak by to byly dva):

<input list="suggest" name="q"
oninput="list.data = '?w=' + encodeURIComponent(value)">
<datalist id="suggest"></datalist>

Kód si můžete vyzkoušet ve všech prohlížečích, které již implementovali WebForms2, tj. zatím jen v Opeře.

Příklad využívá nové značky <datalist> a její schopnosti snadno dynamicky měnit obsah. Není třeba kódovat žádný AJAX, to vše má na starosti prohlížeč. Kodér pouze při změně hodnoty v textovém boxu nastaví vlastnosti datalistu na novou URL a datalist si data získá sám.

Značka <datalist> nebude v HTML5 zdaleka tou nejmocnější. Další možnosti skrývá např. značka <datagrid>, která umožňuje vytvářet vnořené rozbalovací seznamy, ve kterých se bude obsah jednotlivých větví automaticky načítat ze serveru jen v případě, kdy jsou skutečně potřeba.

Pokud se chcete o základních kamenech nových webových formulářů, tzv. Web Forms2, které činí jeden ze základních stavebních kamenů HTML5, přečtěte si WHATWG - budoucnost webu? od Davida Majdy. Zmíněný našeptávač je jen malou ukázkou toho, jak se život webových vývojářů s příchodem HTML5 změní.

Možná přijde i HTTP5

Není to tak dávo, co Anne van Kesteren začal pracovat na XML5. Nedávno Anne experimentoval s interoperabilitou HTTP:

I’ve been wondering about HTTP interoperability for some time now. What if a response has two Content-Type or Location headers? What if newlines are done using 0x0A instead of 0x0D followed by 0x0A?

a možná z toho jednou třeba vznikne i HTTP5:

From what I heard so far RFC 2616bis is not going to address these issues (error handling, thorough interoperability testing, et cetera). gsnedders is working on testing HTTP parsing interoperability and plans to write an HTTP parsing specification which would at least address some of the issues, but in the end we either need the HTTP WG to get their act together or find a lot of free time for HTTP5.

Proč potřebujeme HTML5?

Karl Dubost napsal Why HTML 5 Specification Matters?, příběh jednoho nefunkčního webu v prohlížeči Safari, ve kterém vysvětluje, proč web zoufale potřebuje specifikaci HTML5. Píše:

The browser implementer had clear instructions for this type, was able to implement it, and then to create an interoperable recovery system for this type of mistake. The Web users finally were able to access the Web site without troubles and in the same way than with other browsers. HTML 5 Specification matters because it creates more interoperability when recovering from errors.

Více jsem se o zmíněném problému rozepsal na jiném blogu v Proč HTML5 potřebujeme jak prase drbání?.

Dvě části HTML5

HTML5 lze pomyslně rozdělit na dvě velké části. Tou první jsou novinky (ty tentokrát ocení více weboví vývojáři něž webdesignéři) a tou druhou je jednoduše řečeno oprava stávajícího webu (viz předchozí příklad se Safari).

Vzpomenu příspěvek Fixing the web! od Anne van Kesterena, který se k problematice vyjadřuje:

Apparently it is not very clear what HTML5 is about. HTML5 is not just about introducing new features. 90% of HTML5 is about fixing existing standards.

S těmi 90% to Anne trochu přehání, já bych to odhadoval spíše 50 na 50.

Indeed, HTML5 is mostly about fixing existing standards so they can be implemented interoperably by user agents. These standards include HTML4, XHTML1 and DOM Level 2 HTML as well as defacto standards such as innerHTML.

Pravdou je, že někteří kritici tvrdí, že by k tomu mělo dojít postupně. Napřed "opravit web" a až po té přicházet s novinkami (viz Adamův příspěvek Zastavit inovaci Webu?). Problém je, že web má už v téhle chvíli zpoždění, které by se mu nemuselo v budoucnu vyplatit.

The reason we are introducing new features as well is because we need to innovate the open web to keep it on a level where it can compete with proprietary technology. Focusing on both new features as well as trying to increase the level of interoperability is in my opinion perfectly feasible and also the right way to move forward.

Potřebujeme obojí, jak novinky, tak vyřešení stávajících problémů webu. Zbývá jen doufat, že na ten velký krajíc bude W3C a WHATWG stačit.

Jak by měl vypadat XMLHttpRequest 2

Před pěti dny oznámil Anne van Kesteren vydání working draftu specifikace pro XHR (XMLHttpRequest).

XHR není obsažen v HTML5, byť by tam logicky patřil, pravděpodobně proto, že jeho specifikace začala pod křídly pracovní skupiny pro Web API. Jelikož řada členů Web API WG je zároveň členy WHATWG a HTML WG, není se třeba bát nekonzistencí.

Připravovaná specifikace XHR nepřináší v zásadě nic nového, jejím cílem je hlavně specifikovat XHR tak, jak byl na základě prvotní specifikace Microsoftu implementován webovými prohlížeči a zajistit společný jmenovatel, který bude v každém prohlížeči implementován stejně.

A protože se v zásadě jedná o specifikaci relativně starou (četli jste historii XHR začínající u Outlook Web Access od Alexa Hopmanna?), která neměla ani tušení, jaký boom AJAXu jednou nastane, Anne se zamýšlí, jak by mohl vypadat takový XMLHttpRequest 2. Tedy XMLHttpRequest vyvinutý dle dnešních potřeb.

Srovnejme stávající XHR a Annův návrh XHR2:

// XMLHttpRequest today

function handler() {
if (this.readyState == 4 && this.status == 200)
// so far so good
else if (this.readyState == 4 && this.status != 200)
// fetched the wrong page or network error...
}

var r = new XMLHttpRequest();
r.open("GET", uri);
r.onreadystatechange = handler;
r.send();

//////////////////////////////////////////

// XMLHttpRequest 2

// start "script block"
var r = new XMLHttpRequest(uri);
// uri argument causes implicit invocation
// of r.open("GET", uri)
r.onload = function() { … }
r.onerror = function() { … }
r.onabort = function() { … }
// end "script block" causes implicit invocation
// of r.send()

Anne vkládá URL přímo do konstruktoru, čímž říká, že se má použít XHR2 včetně závěrečného automatického zavolání send() nakonci. A odděluje obsloužení úspěšného a neúspěšného volání (to je již nyní v některých prohlížečích implementováno, ale nebude součástí specifikace XHR1). Ve výsledku je zapotřebí méně kódu a obsluha událostí je strukturovaná.

Pod Anneho příspěvkem se rozpoutala zajímavá diskuse. Terčem kritiky je zejména automatické volání metody send(). Pokud je programování AJAXu vaším denním chlebem a máte nápad, jak XHR vylepšit, napište Annemu do komentářů své připomínky.

BTW všimli jste si, že každá specifikace, kterou Anne píše, má v patičce

Please, keep bugging us with your issues!

Přehled rozdílů mezi HTML5 a HTML4

Anne van Kesteren připravil dokument popisující hlavní rozdíly mezi připravovaným HTML5 a stávajícím HTML4.

Dokument popisuje rozdíly mezi HTML4 a HTML5 a zároveň poskytuje základní zdůvodnění pro tyto změny. Dokument nemusí poskytovat přesné informace, jelikož specifikace HTML5 je stále ve vývoji.

Dokument nebyl zatím pracovní skupinou oficiálně publikován (proto také jeho adresa ukazuje přímo do pracovního repository W3C), ale předpokládám, že v dohledné době se tak stane.

Specifikace HTML jsou psány pro výrobce prohlížečů a nikoliv pro webdesignéry (zajímalo by mne, jaké procento webdesignérů je schopno přečíst celou HTML5 specifikaci a správně jí porozumět, obávám se, že nebude příliš veliké). Pracovní skupina s tím počítá a klade si jako cíl i přípravu dokumentů orientovaných na webdesignéry. Tohle je první z nic. Jsem za něj rád, o potřebě takového dokumentu jsem již psal.

Pokud by vás zajímaly novinky HTML5 rozepsané podobněji, přečtěte si články Davida Majdy WHATWG - budoucnost webu? a Webové aplikace podle WHATWG.

HTML5 na XTech 2007

Anne van Kesteren (WHATWG, Opera) měl na konferenci XTech 2007 prezentaci Evolving the Web: HTML5. Prezentace je vytvořena pomocí CSS media projection, k jejímu shlédnutí proto využijte nejlépe Operu přepnutou do režimu celé obrazovky.

Pětiminutová prezentace ukazuje základní myšlenky HTML5 a stručný přehled nových elementů.

Některé z dalších prezentací konference (již ne nutně o HTML5) naleznete na slideshare.net.

(via Anne)