Výrobci prohlížečů chtějí offline aplikace

Zdá se, že na začlenění podpory offline webových aplikací do HTML5, a tedy i do webových prohlížečů, má každý jiný názor.

Ian Hickson v pátek napsal:

Note: Some people in public-html at w3.org suggested that this would be an area that we should not be working on. However, two separate browser vendors as well as a browser extension developer group have independently contacted me requesting support for this _in person_, as well as by e-mail and over IRC, and in two of those three cases have actively been writing experimental and shipping code to add support for such a feature. This is amongst the highest level of demand I've ever seen for a feature in this spec (the last feature with this level of demand was probably <canvas>). I think it is imperative that we work to obtain a consensus on a single specification for this to enable interoperability on this quite important feature, otherwise we'll see quick fragmentation in this space. I believe HTML is the right place to define this due to the tight integration of any solution here with the loading and browsing context aspects of the current HTML5 spec, as should be obvious from the proposal below.

Výrobci prohlížečů webové offline aplikace skutečně chtějí - vzhledem k objevujícím se alternativním platformám není divu. Zajímalo by mne, výrobci kterého druhého prohlížeče po Firefoxu projevují zmiňovaný aktivní zájem. Citovaní "browser extension developer group" budou nejspíš lidé z týmu Google Gears.

Aktuální návrh specifikace naleznete na konci Hixieho e-mailu, debata je v plném proudu a stále dochází i ke dramatickým změnám.

80 procent případů použití

Někdy se ptáme, proč do HTML nepřidat ještě tuhle vlastnost, nebo tuhle a pak ještě tamtu, vždyť jsou zaručené případy, kdy se to hodí. Nedávno bylo v souvislosti s přidáváním nových vlastností do HTML5 zmíněno pravidlo 80%, neboli Paretův princip. Pokud je Paretův princip pro vás stejně jako pro mně novinkou, čtěte dál.

Ian Hickson píše:

While every USER has to be catered for, the same is not true for every possible use case from the content producer side. For example, at the moment it is not in the scope of HTML to handle writing photo editing applications like Photoshop or movie editing applications like Final Cut Pro. While it may be possible to write such applications in HTML today if you are rather masochistic, it is not something that HTML makes easy, and it is not likely that we will make it easy in HTML5.

We want to keep the language as simple as possible while still catering to the majority of content producers (and while catering to all users).

Note that the "80" value is arbitrary. It is just meant to symbolise the fact that we don't want to cater to all use cases, we only want to cater to the most common ones.

Návrh pro offline webové aplikace přišel na řadu

Již delší dobu se čekalo, kdy se v HTML5 objeví specifikace offline webových aplikací. Že se objeví bylo jisté, netušilo se kdy a zda bude vypadat spíše jako u Firefoxu nebo jako u Google Gears (v obou projektech s implementací offline webových aplikací již nějaký čas experimentují).

Koncem srpna Ian Hickson začal diskusi:

It seems like we are talking about the following kinds of scenarios:

1. User goes to a page, then, without closing the page, goes offline and uses it, then goes back online and continues to use it. The page and its subresources are always at their most up-to-date. Interactions with the page while offline are synced to
the server when going online.

2. User goes to a page, then closes the browser. User restarts the browser while offline, and goes to the page. User restarts the browser again while online, and goes to the page. The page and its subresources are always at their most up-to-date. Interactions with the page while offline are synced to the server when going online.

3. Same as 1 or 2, except that the user is not online for long enough to fully download the updated resources. The application doesn't stop working, it is still usable the second time the user is offline.

My proposal is that we add a new attribute to the <html> element, which flags that the page is a Web app that wants to be pinned for offline execution and that when you next fetch the file or one of its subresources while online, it should try to update all the subresources atomically.

<html application>

Nejedná se o kopii ani jedné ze stávající implementací, více se blíží Google Gears.

Hixie specifikaci zatím psát nezačal, nad podobou specifikace se stále diskutuje, pokud vás zajímá, přočtěte si vlákno Offline Web Apps v mailing listu WHATWG.

HTML pro všechny

Nedávno se objevila nová doména HTML4ALL spojující několik osob částečně kritizujících dění v HTML WG. Vedle wiki obsahuje mailing list s veřejným archivem.

O některých neshodách jsem psal např. v příspěvcích Jak vyřešit problémy webu? a Molly na návštěvě u WHATWG.

Za cca 3 týdny existence HTML4ALL se nestalo nic obzvlášť zajímavého. Skupina přemýšlí, jaké si dá logo a hledá smysl své existence.

Nejsem si zcela jist, kam přesně tuto skupinu zařadit (což je opravdu těžké, když ještě sami nemají úplně jasno, proč existují 8-), skupina si neklade za cíl tvorbu nové specifikace (tedy konkurenci HTML5), spíš mi vyznívá jako jakási kontrolní skupina, která chce sbírat feedback proti některým nedostatkům (alespoň jak nedostatky vidí její členové) připravované specifikace HTML5, které pak hromadně vznese.

V zásadě nic špatného. Pokud by to mělo za následek snížení počtu půtek a nekonečných diskusí v mailing listu HTML WG, které někdy začínaly být osobní (ty by se mohly částečně přesunout do HTML4ALL a zůstaly by hlavně debaty řešící specifikaci), hlasuji pro.

Myslím si, že HTML4ALL v žádném případě není tím, kdo by byl schopen vyřešit problémy dnešního webu, přečtěte si jejich mission statement, ale zastupuje důležitou podmnožinu názorů, která by měla být brána v úvahu (viz nedávný příspěvek).

Pokud však HTML4ALL jako skupina uspěje, najde smysl své existence, získá dlouhodobé členy a vyprodukuje nějaké výsledky, cítím z dlouhodobého hlediska opět další zeslabení vlivu W3C nad vývojem webu.

Kdykoliv se důležité debaty a rozhodování přesunou z půdy W3C jinam, W3C trochu ztratí. A to se poslední dobou opakuje stále častěji, viz WHATWG, Microformats.org a další. To vše jsou zajímavé aktivity, které vznikly proto, že pod křídly W3C nenašly pro sebe vhodné místo.

Křižník W3C pomalu začíná nabírat vodu. Ještě se nepotápí, pluje klidně po hladině, na první pohled není vidět žádný problém, ale nezdá se, že by posádka díry stihla zaslepit dřív, než se spodní paluba naplní vodou až přespříliš. To může nastat až za řadu let, ale čím dál víc se jeví jako neodvratitelné.

Tento příspěvek berte prosím s velkou rezervou. HTML4ALL je právě rodící se miminko a je těžké odhadnout jeho budoucnost.

K sémantickému webu cestou mikroformátů

Nedávno jsem citoval rozhovor s TBL: Budoucnost webu očima jeho tvůrce, který se točil okolo sémantického webu (TBL jej označuje za Web3.0) a zmiňoval jsem mikroformáty, které současné (X)HTML evoluční cestou k sémantickému webu posunují.

Dnes mi na Lupě vyšel článek S mikroformáty přijde Web 3.0, vysvětlující, k čemu mikroformáty jsou, a jaký by mohl být jejich přínos pro další vývoj webu.

Od sepsání článku uplynulo jen pár dní a už jsem narazil na další zajímavé informace týkající se mikroformátů. Pokud bude zájem, zkusím o nich ještě něco dalšího napsat. Jen zatím nevím, zda by to mělo být na HTML456 (ale moc se to sem nehodí, tenhle blog je hlavně o nových verzích HTML a mikroformáty jsou na verzi HTML nezávislé) nebo si nashromáždit víc materiálu na další článek na Lupu.