Zobrazují se příspěvky se štítkemfirefox. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemfirefox. Zobrazit všechny příspěvky

čtvrtek 24. června 2010

Jak funguje geolokace ve Firefoxu - detailní (až vyčerpávající) popis

Často narážím na otázky týkající se geolokace ve webových prohlížečích. Lidé jsou někdy zmateni jejími výsledky. Např. přemýšlí, proč jim jeden počítač vrací jiné údaje než jejich druhý počítač v té samé místnosti apod.

Vysvětlím podrobně, jak funguje geolokace ve Firefoxu. Snad si pak dokážete na vaše otázky odpovědět. Budu se zabývat pouze Firefoxem - ostatní prohlížeče jsem zatím podrobně nezkoumal, ale část zmíněného může být jistě aplikována i na ně.
Pokud chcete komplexní pohled na problematiku, podívejte se na mou přednášku S geolokací by se neztratili ani Jeníček a Mařenka.

Začněme s javascriptovým kódem pro geolokaci

Použít geolokaci na webové stránce je celkem snadné. Stačí na to volání jedné funkce, a sice: navigator.geolocation.getCurrentPosition (viz připravovaný standard W3C).

A pro vyzkoušení: plný funkční příklad (všimněte si panelu hned nahoře, který musíte potvrdit).

Takhle to vypadá snadné. Pojďme se ale podívat, co přesně se odehraje od doby, kdy povolíte vašemu prohlížeči zjištění polohy až do získání výsledných souřadnic. Sami byste si pak měli být schopni odpovědět na otázky typu proč někdy Firefox vrátí polohu přesně (s rozptylem 150 metrů) a jindy ulítne a má rozptyl mnoha kilometrů.

Krok 1. Zjištění geolokačních údajů

Pokud má prohlížeč určit vaši polohu, musí shromáždit údaje potřebné ke geolokaci. Takových údajů je několik. Co je dostupné snad vždy, je vaše IP adresa (resp. veřejná IP brány přes kterou se připojujete k internetu). Srovnáním IP adresy s příslušnou databází je možné odhadnout vaši polohu. Jedná se o geolokační údaj s nejhorší přesností (rozptyl jednotky, desítky, někdy i stovky kilometrů - má pražská IP adresa je lokalizována do centra Prahy s rozptylem 140 km).

Ale lepší něco než nic. S IP adresou téměř vždy určíte správně zemi uživatele, v lepším případě i město, ve kterém se uživatel nachází. (Má to své mouchy. Pokud je např. uživatel z města A připojen k internetu přes VPN v městě B, pak je tímto způsobem jako jeho poloha určeno město B.) Jelikož jakákoliv metoda je lepší než geolokace pomocí IP adresy, použije se IP adresa jen v případě, kdy nic jiného není k dispozici. Jinak se ignoruje.

Má váš počítač Wi-Fi? Pak může být vaše poloha určena mnohem přesněji. Je-li Wi-Fi na vašem počítači zapnutá, načte Firefox všechny přípojné body, které právě vidíte (jejich jména, MAC adresy a sílu signálu) a použije jich k geolokaci (využívá se k tomu celosvětová databáze Wi-Fi přípojných bodů).

Tím možnosti desktopového Firefoxu končí. U mobilních prohlížečů navíc připadá v úvahu ještě využití BTS ve vašem okolí (to funguje na stejném principu jako u Wi-Fi s tím rozdílem, že signál BTS dosáhne dál, tudíž geolokace pomocí BTS bude méně přesná než geolokace pomocí Wi-Fi). A konečně tu je možnost využití GPS zabudované v telefonu.

My počítáme s desktopovým Firefoxem, tudíž známe jen IP adresu a Wi-Fi v okolí.

Krok 2. Dotazujeme se geolokační služby Googlu

Naznačil jsem, že samotná znalost IP adresy ani Wi-Fi bodů nestačí, je potřeba je porovnat s databází, která obsahuje polohu všech (resp. ne všech, ale dostatečného množství) IP adres a Wi-Fi bodů.

Firefox k tomu používá databázi Googlu. (Takových databází je řada, ale Google má asi jednu z největších = nejlepších.) Google sestavil Geolocation API Network Protocol, pomocí kterého může Firefox (nebo i vaše vlastní aplikace, jak si ještě ukážeme) s jeho databází komunikovat.

V about:prefs předvolbách Firefoxu najdete klíč geo.wifi.uri s hodnotou https://www.google.com/loc/json.

To je URL, se kterou Firefox komunikuje pomocí Geolocation API Network Protocolu. Jak taková komunikace vypadá?

Řekněme, že můj počítač "vidí" jednu Wi-Fi s názvem "default" a adresou "00-0e-2e-7d-7d-0e". Požadavek vypadá takto:
{
"version": "1.1.0",
"wifi_towers": [
{
"mac_address": "00-0e-2e-7d-7d-0e",
"signal_strength": -49,
"ssid": "default"
}
]
}
Všimněte si, že protokol kromě hlavičky s číslem verze obsahuje pouze údaje o daném Wi-Fi bodu, nikde v něm nefiguruje údaj o vaší IP adrese. Tu nepotřebuje. Google k tomu použije IP adresu, ze které mu požadavek dorazí.

Pozn.: Pokud byste chtěli komunikaci mezi Googlem a prohlížečem odposlouchávat a máte problém s HTTPS, můžete změnit hodnotu geo.wifi.uri na http://www.google.com/loc/json (všimněte si změny protokolu z HTTPS na HTTP). Pro pouhé zalogování dat, která Firefox odeslal geolokačním protokolem, se mi osvědčila služba http://www.postbin.org/ nastavte geo.wifi.uri na vygenerovaný postbin a sledujte, co Firefox odesílá. (Po otestování vraťte geo.wifi.uri na původní hodnotu.)

K soukromí: Geolokační požadavky neobsahují cookies. To z důvodu ochrany soukromí. Můžete být právě ke Googlu přihlášeni, ale Firefox cookies přihlášeného uživatele na adresu https://www.google.com/loc/json prostě nepošle. Asi namítnete, že kdyby Google opravdu chtěl, může si propojit identitu uživatele pomocí IP adresy a sledovat jej tak. To jistě může.

Na druhou stranu odfiltrováním cookies udělal Google, co bylo jednoduše možné. Vaši IP adresu už odfiltrovat nemůže (pokud bychom do toho nezapojili nějakou třetí stranu, která by prováděla anonymizaci IP adresy, a této straně bychom bezvýhradně věřili...).

Uživateli je ovšem přidělen identifikátor, který si prohlížeč po nějakou dobu drží. Google tak může sledovat pohyb konkrétního uživatele, byť tento uživatel není reprezentován svým cookies (tj. svým googlím účtem, tj. svou identitou), ale náhodně vygenerovaným identifikátorem. Předpokládám, že toto sledování Google využívá pro budování a opravování své celosvětové databáze Wi-Fi bodů a BTS (při geolokaci se totiž jednak určuje vaše poloha, ovšem současně se tak i buduje databáze u Googlu - nádherné inženýrské vyřešení úlohy).

Souhrn: Při geolokaci tedy k jisté rozumné ochraně soukromí dochází, byť je to teoreticky ze strany Googlu překonatelné (kdyby chtěl, tak si vás najde a basta!).


Krok 3. Jak Google určí polohu

Skončili jsme odesláním požadavku na URL https://www.google.com/loc/json.

Google odpoví takto:
{"location":
{
"latitude":50.1001961,
"longitude":14.4228038,
"accuracy":150.0
},
access_token":"2:Ta5Y_rSUZbO4rpJD:_FXkzUcxD1OWG-YM"
}
Výsledek si můžeme zobrazit na mapě. Návštěvníci pražských Ruby srazů a Posledních sobot jistě poznali, že se jedná o známý podnik zvaný Fraktál.

Položka access_token je onem zmíněný identifikátor, který vám Google tímto přidělil a kterým budou označeny další požadavky Firefoxu o geolokaci.

Všimněte si, že pomocí Wi-Fi lze zaměřit opravdu přesně. Stačila jediná Wi-Fi a získali jsme naši polohu s rozptylem 150 metrů!!! Tak to skutečně je. Stejnou zkušenost jsem učinil na řade dalších míst ať již v Praze, Plzni nebo Brně. Geolokace pomocí Wi-Fi je neuvěřitelně přesná.

Ve Fraktálu je ve skutečnosti 3-5 Wi-Fi bodů. V požadavku budou Googlu zaslány všechny, ale jemu stačí jediná z nich (je jedno která).

Výjimky: I v městech existují místa, která nemá Google zaměřena přesně. Na výjimky ale narazíte zřídka a nemívají dlouhého trvání. Databáze Google je samoopravující.

Sledoval jsem několik špatně zaměřených bodů a za několik týdnů až měsíců se jejich poloha upřesnila. Podobně tomu je, když se nějaký Wi-Fi bod přemístí (když se někdo přestěhuje do jiného města vezme si s sebou Wi-Fi router), i v takovém případě, se poloha časem ustálí na novém místě.

(Pozorný čtenář právě objevil možnost, jak snadno vysledovat, kam se odstěhovali jeho sousedé. Pokud s sebou vzali Wi-Fi router, je možné po čase určit jejich nové bydliště s přesností na 150 metrů. A to prakticky v kterékoliv civilizované části Zeměkoule!!!)

V případě, že si pořídíte nový Wi-Fi router, pak se za několik týdnů až měsíců také do databáze dostane. (Pokud přemýšlíte jak, pročtěte si, co znamená wardriving či warwalking.)

Je váš Wi-Fi router v databázi Googlu?

To snadno zjistíte. Připravil jsem k tomu jednoduchý nástroj (jedná se jednoduchou aplikaci, která se přímo dotazuje geolokační databáze Googlu). Stačí, když do textového pole zadáte MAC adresu vaší Wi-Fi ve formátu, který používá geolokační protokol, např. takto:
{"version":"1.1.0","wifi_towers":
[{"mac_address":"00-0e-2e-7d-7d-0e"}]}
a odešlete.

V 90% případů získáte vaši přesnou polohu (na 150m). Pokud ovšem získáte tento obrázek, tak jste jeden z mála případů, které v databázi Googlu nejsou. Pak Google použije IP adresu (jelikož moje aplikace hostuje u Googlu má IP adresu lokalizovanou do jakéhosi městečka v Americe).

Pokud máte nový Wi-Fi router, který Google ještě nezná, nebo pokud jste ze samoty, kterou Google databáze ještě nezná, schválně sledujte, jak dlouho bude trvat, než se v databázi objevíte.

Teď byste měli vědět o průběhu geolokace vše. Nebo ne? Ujasněme si ještě pár faktů.

Wi-Fi je základ

Pokud máte v jedné místnosti dva počítače a jeden z nich má zapnutou Wi-Fi, tak ten s Wi-Fi by vás měl lokalizovat naprosto přesně (na oněch 150m). Zkuste si to na maps.google.com (modré tlačítko vlevo nahoře) nebo na mé javascriptové ukázce na začátku článku. Počítač bez Wi-Fi naopak zcela ulítne a hodí vás nejspíš někam do středu nejbližšího velkého města. Můžete si to vyzkoušet i na tom samém počítači se zapnutou a vypnutou Wi-Fi (někdy je nutné mezitím restartovat Firefox, aby se změna projevila).

Co když Googlu pošlu nekonzistentní data?

I to jsem během svých experimentů zkoušel 8-) Ve standardním požadavku Firefox zasílá seznam Wi-Fi bodů z okolí, Google si najde v databázi jejich polohy a následně z nich stanoví polohu uživatele (pravděpodobně jako střed bodů všech Wi-Fi připojení - v tuto chvíli ignoruje velikost signálu a bere v úvahu pouze polohu bodů).

Co když by dostal požadavek, který by obsahoval současně Wi-Fi body z Prahy i Brna? Co udělá? Hloupý není. Ví, že tak velký signál Wi-Fi nemá. Rozhodne se dle jednotlivých bodů. Pokud mu v požadavku zašlu jeden bod z Prahy a jeden z Brna, nemá dle čeho se chytit a Wi-Fi ke geolokaci nepoužije (stále mu zbývá IP adresa, po které může sáhnout).

Pokud bych zaslal 1 bod z Prahy a 2 body z Brna, pak bude bod z Prahy považován za chybný a Google použije ke geolokaci ony dva Brněnské body (stejnou logikou to funguje i při vyšším počtu bodů).

Všimněte si, že jsme si právě ukázali mechanismus, jaký by Google mohl používat k samoopravování své databáze. Pokud se totiž i se svým Wi-Fi routerem přestěhuji z Prahy do Brna, tak nastane přesně ona výše zmíněná situace. Spustím si geolokaci a můj počítač pravděpodobně uvidí několik brněnských Wi-Fi bodů a jeden (můj) pražský. Pokud by se takový dotaz opakoval dostatečně často, mohl by být můj pražský router považován za přestěhovaný do Brna a jeho poloha v DB by se zaktualizovala.

Jsou to dohady, Google veřejně nespecifikoval, jak přesně svou databázi udržuje. Což asi nikdy neudělá, protože jinak bychom ho mohli správně zvolenými požadavky dokonale zblbnout a celou databázi mu rozházet.

Závěr

To jde ode mě vše. Čím víc jsem tenhle mechanismus zkoumal, tím víc se mi líbilo, jak je navržen. A na závěr mám malou prosbu. Pokud jste někdo zkoumal, jak funguje geolokace v dalším prohlížečích, dejte mi vědět (stačí mi i informace, zda používají také databázi Googlu nebo jinou).

Na úplný závěr děkuji Davidu Majdovi, Pavlu Cvrčkovi a Marušce Grafové, kteří mě byli nápomocni při testování geolokace v Praze a dalších městech.

pátek 11. prosince 2009

První verze akcelerovaného 3D v prohlížečích je na světě

Pod hlavičkou Khronos Group byl vydán první draft specifikace WebGL. K této aktivitě se hlásí Apple, Google, Mozilla i Opera (absence Microsoftu se u podobných aktivit již stala pravidlem).

Práce začala loni na jaře, kdy se výrobci sice již shodli, že akcelerované 3D na webu bude časem nutností, ale nebyli se schopni dohodnout, jak má toto rozhraní vypadat a začali si (téměř každý) vyvíjet své vlastní. Právě včas zasáhl Khronos Group, který přinesl nejen neutrální půdu pro přípravu nového standardu, ale také potřebné know-how (pod jeho patronátem se vyvíjí např. OpenGL). Zřejmě se jednalo o dobrou volbu, protože se výrobci prohlížečů (ti jmenovaní) přidali.

Chcete si to vyzkoušet? Máme implementace

Současně s první pracovní verzí specifikace jsou k dispozici i její první implementace. (Také začínáte mít pocit, že v Khronos Group to šlape poněkud lépe než u W3C?) Jedná se zatím o experimentální implementace dostupné jen pro testování. Jednu najdete v nočních buildech Firefoxu (návod, jak ji zapnout), další najdete v Chromiu a nočních verzích WebKitu.

Pro vyzkoušení nových 3D možností si zkuste dema nebo stránku x3dom.

Já tleskám a jdu si to také zkusit.

P.S.: Ještě k Microsoftu. Komunikace na Twitteru mezi Arunem (Mozilla) a Chrisem Wilsonem (Microsoft): upozornění, reakce, reakce, reakce.

Firefox 3.6 zlepší práci se soubory ve formulářích

Ve Firefoxu 3.6 se dočkáme dvou novinek týkajících se práce se soubory. Tou první je podpora uploadu více souborů najednou z jednoho formulářového pole po vzoru specifikace HTML5 (dříve WebForms2).

Zápis vypadá jednoduše:

<input type="file" multiple="">

v HTML variantě jej můžete zkrátit i na:

<input type=file multiple>

Pomocí JavaScriptu můžete ověřit, kolik souborů uživatel vybral nebo je (resp. jejich názvy) v cyklu projít (kolekce input.files a vlastnost input.files.length
).

Více: ukázka, specifikace.

Sáhněte si na soubor

Tou druhou novinkou je možnost přistupovat přímo z JavaScriptu k obsahu souborů, které uživatel vybral k uploadu pomocí klasického <input type="file">. Dosud bylo totiž nutné takové soubory nahrát na server, z něj získat zpět a teprve pak s nimi šlo dále pracovat. Alternativou bylo použití pluginů, které umožňovaly přímou práci se soubory.

Z JavaScriptu bude pomocí nového API možné zjistit nejen název takového souboru, jeho typ a velikost, ale také přistupovat k jeho obsahu a to třemi asynchronními způsoby (dnes už je takový trend dělat všechny náročnější operace asynchronně, aby nedocházelo k zamrzání stránky v prohlížeči) :
  • readAsBinaryString
  • readAsText
  • readAsDataURL
Zvolená metoda se váže na typ obsahu a co s ním chcete dělat. U textových souborů použijete readAsText. Pokud chcete pracovat s obrázky, ale nemáte v úmyslu je měnit, zvolíte readAsDataURL (následně do vlastnosti můžete img.src nastavit přímo tuto hodnotu a obrázek se zobrazí) atd.

Kompletní specifikace (poměrně čerstvá, první návrh přišel před pár týdny právě od Mozilly) počítá i s výše zmíněným přepínačem multiple (bude tedy možné např. označit všechny fotografie v adresáři a následně s nimi v JavaScriptu pracovat).

Firefox 3.6 zatím neimplementoval specifikaci celou, ale dost na to, aby si ji zájemci mohli vyzkoušet (stahujte Firefox 3.6 beta 4).

Více: video s demem, ukázka, specifikace.

Pozn.: Firefox 3.6 těch novinek přinese víc, ale pro účely tohoto příspěvku nejsou podstatné.

Pozn. 2: Specifikace je nová a zatím jsem nenašel reakce dalších prohlížečů, zda ji budou chtít podporovat nebo ne. Uvidíme.

úterý 6. října 2009

HTML5 video bude mít v novém Firefoxu podporu fullscreenu

Celoobrazovkové přehrávání videa je na webu běžné. Pamatuji si, že okolo HTML5 specifikace před pár lety probíhala debata, zda a jak začlenit podporu fullscreenu.

Pokud mě paměť neklame, nakonec se do specifikace požadavek fullscreenu nedostal. Prohlížeče, jej podporovat mohou, ovšem je na nich zda a jak to učiní.

Firefox je první prohlížeč, který se o to pokouší. Pokud si stáhnete noční build Firefoxu můžete si např. na testovací stránce The Video Bay pustit video a v kontextové nabídce zvolit položku "Full Screen".



Předpokládám, že další prohlížeče podporující HTML5 video budou rychle následovat a podporu pro fullscreen rovněž přidají.

čtvrtek 16. července 2009

Vyzkoušejte si nové drag and drop API ve Firefoxu 3.5

Jednou z novinek HTML5 je API pro drag & drop. Implementuje ho i nedávno vydaný Firefox 3.5. API nevzniklo na zelené louce, bylo vytvořeno dle implementace v Internet Exploreru a její kopie v Safari.

Pro implementaci drag & drop podle nového API již není třeba používat nízkoúrovňových událostí typu mousedown a mousemove, můžete sáhnout po událostech typu dragstart, dragend atd.

Demo

Výsledek si můžete ve Firefoxu 3.5 vyzkoušet na sadě ukázek.

Zdrojový kód je diskutovaný v článku HTML5 drag and drop in Firefox 3.5.

Připravil jsem i minimální kód potřebný pro zahájení drag & drop procesu.

Jelikož počet vývojářů, kteří používají nativní JavaScript klesá, klesá i význam téhle zprávy. Z událostí DOMu se pomalu stává cosi nenápadného, co se schovává kdesi dole pod frameworkem, který jejich obsluhu bezchybně zvládne.

I přesto je dobré minimálně vědět, že takové nové API existuje, abyste jednou nebyli překvapeni, a nepřemýšleli, kde se ta záhadná událost dragleave vlastně vzala.

Aktualizace

Vizionáře v oboru webových aplikací jistě nadchne fakt, že tento mechanismus funguje i napříč doménami, tj. můžete provádět drag & drop třeba mezi Emailem na Seznamu a Google Docs. A na těchto aplikacích pak záleží, zda se spolu dokáží domluvit.

čtvrtek 9. července 2009

Noční buildy Firefoxu obsahují parser HTML5

Když si stáhnete noční build Firefoxu a nastavíte v něm html5.enable na true, začne Firefox používat parser HTML5.

Jelikož parser HTML5 je historicky první pokus o standardizaci parsování HTML, pak Firefox je historicky první prohlížeč, který může používat standardizovaný parser HTML.

Myšlenka vedoucí ke standardizaci parsování HTML je prostá: zvýšit interoperabilitu mezi prohlížeči, čili zvýšit pravděpodobnost, že pokud vám stránka funguje v jednom prohlížeči, bude fungovat i v dalších (a pokud možno stejně).

Autorem této implementace je Henri Sivonen, který původně vytvořil parser HTML5 v Javě (ten dnes mj. používá i oficiální validátor HTML od W3C pro validaci HTML5). Kód pro Firefox byl vytvořen automatickou konverzí z Javy do C++.

Neznamená to ovšem, že by Firefox měl v nejbližší době přejít na tento parser. Jedná se zatím pouze o experiment a historicky první ověření, zda můžeme na dnešní web takový parser vůbec pustit, zda bude všechno fungovat a zda se pod ním naše oblíbené stránky zcela nezhroutí.

Parser HTML5 totiž nemá umět parsovat jen HTML5, ale má umět parsovat stávající HTML používané všude na webu, ať už se jedná o HTML3, HTML4 nebo o XHTML1.

Doposud byl standard parseru HTML5 ověřován hlavně automatickými testy u Google, kde byl spouštěn na několik miliónů stránek ležících v cachi Googlu a následně byly analyzovány zalogované výsledky. Nyní poprvé může výsledek parseru HTML5 vidět uživatel ve svém prohlížeči. Tím se mohou objevit problémy ve specifikaci, na které dosud nikdo nenarazil.

Nejedná se proto ani tak o přínos pro prohlížeč Firefox, jako o přínos pro budoucnost HTML, konkrétně pro zvýšení kvality specifikace HTML5.

Související

středa 15. října 2008

Předvolba pro vypnutí autoplay videa

Když jsem nedávno předváděl podporu videa ve Firefoxu a o něco dříve podporu videa v Safari, stěžoval jsem si, že oba prohlížeče umožňují spustit video i s vypnutým JavaScriptem (to specifikace nařizuje - jedná se o autribut autoplay), ale neumožňují uživateli tuhle funkci vypnout (o tom se specifikace nijak nezmiňovala).

Velmi mě potěšilo, když včera do HTML5 specifikace přibyl odstavec, který doporučuje prohlížečům nechat uživatele tuhle funkci vypnout. Podobně autorům stránek je doporučováno automatické spouštění řešit atributem autoplay a nikoliv skriptováním:
User agents are not required to autoplay, and it is suggested that user agents honor user preferences on the matter. Authors are urged to use the autoplay attribute rather than using script to force the video to play, so as to allow the user to override the behavior if so desired.
Už se těším, až se v prohlížečích takové funkce objeví. Přeci jen uživatel má být vždy tím, kdo má svrchované právo rozhodnout, jak se prohlížeč bude chovat.

neděle 21. září 2008

Když si Firefox zapingá

Firefoxu 3 implementoval atribut ping z HTML5. Možná jste si toho ale vůbec nevšimli. To proto, že podpora pingání je po instalaci vypnuta. Pokud ji chcete zapnout, nastavte na stránce about:config předvolbu browser.send_pings na hodnotu true.

K čemu je takové pingání dobré? Pokud se pozorně podíváte prakticky na jakýkoliv vyhledávač, zjistíte, že na stránce s výsledky hledání pečlivě monitoruje, na které nalezené odkazy klikáte a na které ne.

(Úkol pro zvídavé: Podívejte se, jak takový monitoring dělá Google, jak Seznam a zamyslete se, proč je způsob zvolený Seznamem rychlejší, byť méně přesný. A také proč oba vyhledávače zapomněly na uživatele nepoužívající myš.)

Monitoring klikání na odkazy se ovšem nehodí jen pro vyhledávače. Když jsme kdysi v CZille přemýšleli, jak udělat počitadlo stažených Firefoxů z našich stánek, došli jsme také k pingacímu řešení. Prosté logování hitů na stahovaný soubor nelze použít, v tom se vám projeví i roboti.

Pingání
tak není jen pro velké firmy s vyhledávači, ale prakticky pro každého, kdo monitoruje pohyb uživatelů na svých stránkách. Předpokládám, že nástroje jako Google Analytics budou atribut ping po jeho zavedení také využívat.

Proč zavést ping atribut?

Pokud se některá technologie hojně používá a její použití (správný zápis) je zbytečně komplikované, mělo by se zjednodušit. Pokud jste se dívali, jak mají pingání implementováno i Googlu a Seznamu, asi uznáte, že o jednoduchosti se nedá hovořit. Jenže ono to zatím o moc líp udělat nejde.

A přesně to řeší atribut ping u odkazu (nebo u značky area). Jeho použití je snadné:

<a ping="http://www.example.cz/ping" href="http://www.example.cz/">Odkaz</a>

Pokud uživatel přejde na odkaz, je zároveň poslán požadavek na adresu uvedenou v atributu ping. Pokud je v atributu ping uvedeno více adres oddělených mezerou, pošle prohlížeče požadavek na všechny uvedené adresy.

Požadavek je zaslán metodou POST a pokud adresa v atributu ping a adresa aktuálního dokumentu jsou ze stejné domény, pošlou se v požadavku i další hlavičky: Ping-From a Ping-To (obsahuje adresu odkazu, na který uživatel přechází).

Výhody
  • Již zmíněná jednoduchost.
  • Přesnost - mechanismus funguje i pro uživatele bez myši, dokonce i pro uživatele bez JavaScriptu. (Přesnost pochopitelně bude platit jen v případě, že všechny prohlížeče atribut ping implementují.)
Implementace ve Firefoxu

Atribut ping byl zatím implementován jen ve Firefoxu 3. Jedná se spíše o implementační experiment sloužící pro zpětnou vazbu při tvorbě HTML5 specifikace a ve výchozí instalaci je vypnut.

Všiml jsem si, že Firefox posílá požadavek pouze na první adresu v atributu ping. Pokud je jich víc, ponechá ostatní bez odezvy (to je chyba v implementaci).

Soukromí uživatelů

A co na to uživatelé? Co když se jim takové sledování nebude líbit? Pokud byli paranoidní, pomohl jim vypnutý JavaScript, atribut ping ale funguje i bez JavaScriptu.

Myslím, že uživatelé můžou klidně spát. Pravděpodobně každý prohlížeč nabídne možnost atribut ping vypnout. Ať již pro běžné používání nebo v soukromém módu (přezdívaném porno mód), který se dnes již stal standardem a dříve či později jej budou obsahovat všechny prohlížeče.

Přesto se nemůžu zbavit pocitu, že se prohlížeče tomuto atributu vyhýbají. Jeho implementace je velmi jednoduchá, ale kromě Firefoxu se do ní zatím nikdo jiný nepustil. Že by byly opatrní a nechtěly být označeni za prohlížeč omezující soukromí uživatele? Kdo ví!

čtvrtek 18. září 2008

Ukázka podpory videa ve Firefoxu 3.1

Vývojová verze Firefoxu 3.1 Alfa 2 podporuje značky video a audio z HTML5. Já se jí podívám trochu na kobylku podobně jako jsem to před půl rokem udělal se Safari. Implementace sice není kompletní a obsahuje chyby (jednou se mi podařilo prohlížeče dokonce shodit), ale pro základní popis obou značek prozatím postačí.

Pokud chcete vidět rovnou celý výsledek, zobrazte si testovací stránku, já zde jednotlivé možnosti značek <video> a <audio> rozeberu podrobněji.

Video

Začneme videem, protože je zajímavější. Firefox v tuto chvíli podporuje pouze formát OGG Theora, v budoucnu by se mohlo spektrum rozšířit, ale to není zajím ještě jasné. Diskusi o formátech nechám na jindy, dnes se soustředím na kód HTML a JavaScriptu, kterým se video vkládá a ovládá.

Vzal jsem HTML5 trailer (krátké video, které jsem loni vyrobil) a převedl jej pro účely výkladu do OGG formátu. Má asi 5MB, proto pokud máte pomalé spojení, vydržte, až budete zkoušet příklady níže, než se poprvé načte. Pro další zobrazení by už měla zafungovat cache.

A můžeme udělat první pokus: zobrazit video v prohlížeči. Tady Firefox trochu zklamal, pokud mu video předložím přímo, nabídne mi stažení, ale netváří se, že by je uměl zobrazit (na to jsem se těšil). Škoda, takže pro zobrazení videa musíme vytvořit webovou stránku, do které video vložíme. (Pro srovnání u obrázků to není nutné, ty prohlížeč dokáže zobrazit i přímo, nepotřebuje k tomu webovou stránku).
  • Nejjednodušší příklad vložení - k vložením nám stačí značka video s nastaveným atributem src. Musíme pamatovat na přístupnost a pro prohlížeče, které značku video nepodporují, vložíme tzv. fallback obsah, který zobrazí místo videa. V našem případě postačí, když dovnitř značky video vložíme odkaz ke stažení. JENŽE video nám jaksi nefunguje že? Po načtení ze zobrazil první snímek, ale ne a ne se spustit. Inu zatím jste ho zobrazili, ale ještě nespustili.
  • Vložení s ovládacími prvky - přidáme atribut controls. Prohlížeč nám má nyní nabídnout ovládací prvky. A můžeme si video spustit. Video nám krásně běží a můžeme si je i zastavit. Všimněte si, že ovládací prvky jsou vykresleny plně v zobrazované oblasti videa, nijak nezasahují do okolní stránky (webdesigner tedy nemusí řešit který problížeč jak prvky vykreslí, nezajímají ho). BTW doufám, že je stávající podoba jen dočasná, protože se Safari, které zobrazí kompletní ovládací prvky včetně pozastavení videa, timeline, rychlého převinu a vypnutí zvuku, se nedá srovnat. Aktualizováno: Pracuje se na zlepšení.
  • Malá varianta s autoplay - předchozí příklad, ale s přidaným atributem autplay, jehož význam jste jistě odhadli.
  • Ovládáme video sami - pokud nechceme, aby ovládání zajišťoval prohlížeč, žádný problém. Když ale nevložíme atribut controls, musíme ovládací prvky nabídnout uživateli sami (jinak video nedokáže ani spustit, natož již spuštěné video zastavit). V tomto příkladu uvádím tu nejjednodušší možnost (kliknutím na video je spustíte nebo naopak zastavíte), v reálu bychom zvolili nějakou intuitivnější metodu, např. umístění pěkných tlačítek pod videem.
  • Nastavení rozměrů - video je klasický blok, můžeme mu vnutit jakékoliv rozměry (a za pomoci SVG nebo CSS transform jím dokonce otáčet).
Značka video toho umí víc, ale jedná se buď o pokročilé vlastnosti nebo o vlastnosti, které Firefox zatím neimplementoval (zobrazení posteru, obsluha událostí atd.). Necháme si je proto na jindy. Pokud jste z Brna a okolí, můžete si přijít poslechnout mou přednášku na konferenci LinuxAlt 2008, kde se toho dozvíte víc a nejen o videu.

Audio

Firefox podporuje opět jediný kodek a to OGG Vorbis. Podobně jako u značky video není zatím ani podpora značky audio kompletní. Postačí nám proto jen jedna ukázka
  • Ukázka audia - na zobrazené stránce sice nic neuvidíte, zato uslyšíte hudbu na pozadí. To proto, že jsem přidal atribut autoplay. Bez něj byste mohli hudbu spustit (a opět zastavit) JavaScriptem. Dalším řešením by bylo přidat atribut controls, který by měl podobně jako u videa uživateli zobrazit ovládací prvky. Ten ovšem ve Firefoxu zatím nefunguje.
Když prohlížeč nejde ztišit

Malé zamyšlení. Jak se poslední příklad zachová, pokud budete mít vypnutý JavaScript?

Podobně jako v Safari se obsah značky audio spustí, i když je vypnutý JavaScript (to je správně) a toto chování nejde změnit (to je špatně).

Doufejme, že než se podpora audia dostane do ostré verze, tak se nějaké nastavení objeví. Jinak by to totiž znamenalo konec poslední tiché bašty. Dosud jste měli možnost, pokud jste chtěli prohlížet web v tichosti, vypnout JavaScript, pluginy a měli jste celkem jistotu, že vás prohlížeč nevyruší. S příchodem značky audio tato jistota padá. Doufejme, že se v prohlížečích objeví aspoň možnost i tento mediální obsah vypnout.

A tím končí dnešní stručné představení značek <video> a <audio>. Více najdete v HTML5 specifikaci v sekcích Video Element, Audio Element, Media Elements a Source Element.

Jak vytvářet OGG Theora

Dotatek pro ty, kdo chtějí vytvořit video s kodekem OGG Theora a neví jak. Stačí když:
  • stáhnete ffmpeg2theora
  • zkonvertujete jím existující video (z příkazové řádky takto: ffmpeg2theora video.avi)
  • výsledek můžete přehrát třeba ve Firefoxu 8-) nebo si stáhněte přehrávač VLC, případně samotný kodek

středa 3. září 2008

Firefox implementuje drag & drop z HTML5

Poslední noční buildy Firefoxu obsahují podporu pro drag & drop z HTML5. Naprogramování drag & drop bylo dříve v prohlížečích poněkud komplikované (bylo nutné odchytávat události myši, detekovat, že uživatel chce s prvkem vůbec hýbat, vykreslovat jeho posunování a znovu detekovat, kam byl spuštěn).

Specifikace HTML5 obsahuje API, které je mnohem jednodušší. Rozhraní nenavrhli autoři specifikace, nýbrž vývojáři Internet Exploreru. Jedná se o další případ, kdy se HTML5 snaží standardizovat prohlížečem zavedené rozšíření. Nové rozhraní po Internet Exploreru implementovalo Safari a nyní došlo i na Firefox.

Rozhraní definuje nové události:
  • drag
  • dragstart
  • dragenter
  • dragleave
  • dragover
  • dragend
  • drop
a řadu obslužných metod např. setDragImage nastaví obrázek, který bude uživateli zobrazovat, že právě "něco myší tahá".

Nedaří se mi najít najít žádné funkční demo, leda tento příklad, který nevím proč nefunguje. Navíc whatwg.org je dnes nedostupný (všichni zkouší nový prohlížeč od Googlu, chtějí testovat na acidtests.org a přetížili tak Hixieho server). Větší rozbor tedy necháme na jindy, zatím si můžete přečíst dokumentaci u Mozilly.

Aktualizace: Našel jsem příklad, který funguje (zatím alespoň v IE a Safari).

(Zdroj: Xulplanet.com)

čtvrtek 28. srpna 2008

Firefox asi implementuje window.toStaticHTML z IE8

Součástí přicházejícího Internet Exploreru 8 je i nová metoda windows.toStaticHTML. Ta z jakéhokoliv HTML fragmentu udělá fragment bezpečný, zcela zbavený skriptů. Ve světě dennodenních XSS problémů je to užitečná věc. Zejména, protože se blíží crossdomain-AJAX (samostatná specifikace) a crossdomain zasílání zpráv mezi okny (součástí HTML5).

Také vývojáři Firefoxu uvažují o implementaci toStaticHTML. V tuto chvíli se jedná o nestandardní rozšíření ze strany prohlížečů, pokud se ovšem k implementaci rozhodne i Firefox (a pravděpodobně se rozhodne), bude toStaticHTML na tuty zařazeno do specifikace HTML5.

Proč? Historie nás poučila, že pokud cokoliv implementují dva prohlížeče na vrcholu žebříčku popularity (a to IE a FF jsou), ostatní ono "cokoliv" implementují rovněž. A je lepší, pokud to rovnou implementují správně (resp. interoperabilně = každý stejně), než aby několik let po implementaci vychytávaly chyby.

Všimněte si, nakolik se dnešní situace liší od doby před takovými šesti lety, kterou někteří z nás asi ještě pamatují. Tenkrát často trvalo roky, než se jeden prohlížeč odhodlal k implementace nestandardního rozšíření jiného prohlížeče (document.all, innerHTML, contenteditable a další). Dnes jde vše neuvěřitelně rychle (toStaticHTML byla oznámena letos na jaře a ještě ji nikdo nestačil ani začít používat). Prohlížeče jsou pod vzájemným drobnohledem a nechtějí si nechat ujet vlak.

Pokud se implementace včas podchytí, může i tato nestandardní situace proběhnout zcela bez problému a webdesigneři nakonec budou jásat nad novou vlastností webových standardů, aniž by měli potuchy, že se ve skutečnosti jedná o standardizované nestandardní rozšíření. To jim je ostatně šumafuk.

středa 18. června 2008

Co z HTML5 je ve Firefoxu 3

Vyšla trojková verze Firefoxu a oproti své předchozí verzi kromě uživatelských novinek obsahuje i novinky v podpoře vnikající HTML5 specifikace.

Pokud čtete tento blog pravidelně, tak o většině novinkách nejspíš už víte. Pokud ne, můžete si buď zpětně projít příspěvky se štítkem Firefox nebo nahlédnout do následujících třech příruček.

Field Guide to Firefox 3

V oficiální příručce Field Guide to Firefox 3 najdete stručnou zmínku o hlavních vývojářských novinkách. Zmíněn je HTML5 canvas s jeho textovým API (pozor to je zatím nekompatibilní s HTML5), offline webové aplikace a registrace protokolů k webovým aplikacím.

Zajímavé jsou ale i novinky v podpoře CSS a API pro mikroformáty.



Firefox 3 Revealed


Druhou příručkou je Firefox 3 Revealed, kterou připravil server SitePoint. Napřed musíte registrovat svou mailovou adresu, na tu vám přijde odkaz pro stažení třicetistránkového PDF s krásnou liškou na titulní stránce (je to skutečně liška na rozdíl od pandy, která je v logu Firefoxu, zřejmě malý vtípek SitePointu):

I tato příručka se soustředí hlavně na uživatelské rozhraní, najdete v ní ale i část zaměřenou pro vývojáře nazvanou A Developer’s Dream, která stručně popisuje tvorbu offline webových aplikací. Následuje vyjmenovaný přehled podpory HTML 5 (canvas, contentEditable, drag&drop API, atribut ping a posílání zpráv mezi dokumenty) a dále novinky v podpoře CSS, JavaScriptu a SVG.

Firefox 3 for developers

Mnohem víc informací, často i s detailně popsaným API a příklady, pak najdete na oficiální stránce Firefox 3 for developers.

čtvrtek 5. června 2008

Firefox 3 a canvas s textem

Rozhraní canvasu ve Firefoxu 3 bylo rozšířeno o funkce pro zobrazování textu. Píše o tom Vladimir Vukičevič v příspěvku HTML Canvas in Firefox 3 na svém blogu.

Pokud používáte trojkovou řadu Firefoxu, uvidíte na příkladu Path text velký nápis Mozilla, okolo kterého se "plazí" první odstavce z Mozilla Manifesto.

V jiných prohlížečích text neuvidíte. Je to proto, že Mozilla přišla s vlastním API pro vykreslování textu. Canvas žádné API pro text neměl a původně se o něm ani neuvažovalo. Mozilla proto implementovala čtyři funkce označené vendor specific prefixem moz (mozDrawText, mozMeasureText, mozPathText, mozTextAlongPath).

Teprve nedávno se začalo pracovat na oficiálním textovém API pro canvas. Jeho příprava a implementace ještě nějaký čas potrvá.

Mezitím vývojářům nic nebrání používat nové API Firefoxu 3 (pokud dobře zváží fakt, že není v jiných prohlížečích podporováno), prefix moz zajistí, aby se tyto funkce do budoucna nedostaly do konfliktu se vznikajícím standardizovaným textovým rozhraním, které se dostane až do některé z dalších verzí Firefoxu.

středa 21. května 2008

Krůček po krůčku ke stejnému (X)HTML

Nedávno jsem na Slashdotu četl příspěvek Why Firefox 3 is Bad for Developers. Pisatel se v něm diví, proč následující zápis, ačkoliv fungoval ve Firefox 2, ve Firefoxu 3 nefunguje:
<head>
<script type="text/javascript" src="URL" />
</head>
Firefox 2 si neuzavřenou značku script uzavře, zatímco Firefox 3 ji nechá otevřenou a výsledná stránka pak nefunguje (stejně se chovala i původní Mozilla Suite a stejně se chová třeba i Internet Explorer).

Zdůrazňuji neuzavřenou značku script, protože pokud pokud je výsledný kód posílán s MIME text/html jako v citovaném případě, nemá koncové lomítko žádný význam a značka je neuzavřená. To by bylo samo o sobě na delší povídání, mě teď zajímá onen fakt, že zatímco "jedna" verzi prohlížeče se chovala nějak, další verze se chová "nějak jinak", což je také důvod, proč se onen vývojář zlobí.

Všimněte si, že mezi agumenty pro změnu, které vývojář Gecka Boris Zbarsky uvádí, je, že HTML5 toto chování vyžaduje. Je to jeden z mnoha požadavků z té části HTML5, která nepřidává do HTML žádné nové vlastnosti, ale upřesňuje ty stávající až do (aspoň podle autorů) všech nutných detailů.

Noční můra webdesignerů aneb na co jsme si zvykli

V tomto případě jsou obě varianty (jak <script></script>, tak <script />) z pohledu XHTML správné, a jsou také obě validní, ovšem ta druhá v některých prohlížečích fungovat nebude. Svět prohlížečů je tak pro vývojáře noční můrou, protože ačkoliv píše podle učebnic, validuje svůj výsledek a podívá se na něj ve svém prohlížeči, nic mu nezaručí, že to celé bude fungovat i v některém z dalších prohlížečů. A výše zmíněný případ je jen jedním z mnoha.

A ačkoliv jsme si na to zvykli, někde uvnitř každého webdesignera určitě hlodá pochybnost, že to tak vlastně ani nemuselo být. Že se jen někde stala chyba a nikdo ji zatím neopravil.

A tím se od současné noční můry dostáváme k pohádce (ono se to zatím jinak než pohádka nazvat nedá).

Pohádka pro webdesignéry

Pokud se máme jednoho krásného dne probudit, otevřít okno (myšleno prohlížeče) a zjistit, že (X)HTML je ve všech prohlížečích interpretováno nachlup stejně (a tento pohádkový cíl skutečně je jeden z cílů HTML5), pak to znamená, že chování každého dnešního prohlížeče se musí trochu změnit. Tu více, tu méně. Při tom se nevyhneme tomu, že co včera v jednom prohlížeči fungovalo, v něm nemusí fungovat zítra (viz ten případ s Firefoxem 3). To je daň, které se nelze vyhnout.

HTML5 se snaží ono "jednotné chování (X)HTML" definovat tak, aby bylo pokud možno kompatibilní se stávajícím chováním většiny prohlížečů a stávajícím používáním (X)HTML na Webu. Tedy, aby ta daň byla co nejmenší. Jako vedlejší efekt se tak zároveň vzdaluje teoretickému návrhu ideálně čistého HTML, právě proto, že se tu a tam musí přizpůsobit (což je druhé zdanění).

A kdy že to bude?

Zatím se k pohádkovému cíli jednotného (X)HTML krůček po krůčku blížíme, viz ten případ s Firefoxem, který je jen jedním z mnoha. V nejbližších 5 letech se ho určitě nedočkáme, ale pokud se splní představy tvůrců HTML5, měl by nastat do ukončení vývoje specifikace, tedy odhadem někdy do roku 2022.

Pak se možná splní rčení Iana Hicksona Things that are impossible just take longer. A pak uvidíme, zda se tahle pohádka pro další generace webdesignerů stane skutečností nebo zůstane navždy jen pohádkou.

Tak a teď dobrou noc děti, ráno vás opět čeká vaše noční můra, aspoň prozatím.

sobota 12. dubna 2008

Firefox 3 umí uložit obsah canvasu

Canvas je novou HTML značkou, která umožňuje vývojářům kreslení přímo do webové stránky. Nedávno jsem si všiml, že se v uživatelském rozhraní Firefoxu 3 objevila možnost uložit canvas jako obrázek.

Canvas sám o sobě podporuje vygenerování fyzického obrázku. Vývojářům stačí zavolat jeho metodu .toDataURL(), která vygeneruje obrázek z aktuálního obsahu canvasu. Vývojáři tak mohou nabídnout uživateli vygenerovaný obrázek ke stažení nebo naopak uložit vykreslený obsah canvasu na server. Vyzkoušet si to můžete na jednoduchém příkladu (obrázek vygenerujete přímo kliknutím na canvas).

Firefox 3 jde ale ještě o krok dál a nabízí stejnou možnost přímo v uživatelském rozhraní. Z pohledu uživatele se tak zastírá rozdíl, co je skutečný obrázek, a co je obrázek vykreslený canvasem. Oba se navenek chovají stejně a uživatel mezi nimi ani nemusí poznat rozdíl.



Vyzkoušet si to můžete například na stránce Canvex (pěkný pokus o implementaci Dooma připomínajícího herního enginu v prohlížeči). Kdykoliv zobrazíte na hrací ploše kontextové menu, můžete si ve formátu PNG uložit obrázek aktuálního dění ve hře.

Jsem zvědav, zda se tím budou inspirovat i ostatní prohlížeče.

čtvrtek 3. dubna 2008

Video bude ve Firefoxu i pro mobily

Práce na podpoře nové HTML značky video ve Firefoxu stále pokračují. Zajímavou novinkou je použití GStreameru, což pokud dobře chápu umožní prohlížeči přehrávat video nejen pomocí vlastních kodeků prohlížeče (v tuto chvíli pouze OGG Vorbis), ale i využít některé kodeky nainstalované na uživatelově počítači.

Christopher Blizzard se úspěšně pokusil sestavit experimentální verzi pro mobilní zařízení a zdůrazňuje, že podpora videa v prohlížečích nemá význam jen pro desktop, ale i pro další zařízení, na která Firefox do budoucna míří. Jak se mi to povedlo, posuďte sami.



Pokud se zajímáte o platofrmu Maemo, můžete si Chrisův build vyzkoušet.

neděle 2. prosince 2007

3D canvas pro Firefox

Po Opeře, která vydala verzi s 3D canvasem přišel nedávno s třetí dimenzí i prohlížeč Firefox. Zatím v podobě rozšíření pro Firefox 3.x.

Autor implementace Vladimir Vukićević o ní říká:
There are two contexts provided by the extension. "moz-gles11" follows the OpenGL ES 1.1 spec very closely, providing an almost identical API and feature set, and "moz-glweb20" follows OpenGL ES 2.0 closely. Both are implemented directly on top of desktop OpenGL, so you must have support for at least OpenGL 1.5 on the desktop for the "moz-gles11" context and OpenGL 2.0 for the "moz-glweb20" context.
Na rozdíl od Opery, která zvolila návrh vlastního jednoduchého API se 3D rozhraní Firefoxu drží standardu OpenGL. To jej více přibližuje stávajícím tvůrcům OpenGL aplikací, ale činí jej cizí webovým vývojářům (přiznejte se, kdo z vás umí OpenGL?).

Vlado se domnívá, že se objeví nadstavbové knihovny, které OpenGL rozhraní v sobě skryjí a nabídnou webovým vývojářům jednoduché ovládání.

Jaký přístup byste preferovali vy?

(via: Vlad1.com)

pátek 5. října 2007

Podpora videa již ve Firefoxu 3?

Přiznávám, že jsem již trochu pochyboval, zda se podpora videa dostane do blížícího se vydání Firefoxu 3. Dnešní reakce v Bugzille ukazuje, že šance tu ještě je. Jonas Sicking píše:
Honesly, if this is in a state where we're ready to land it on trunk then I think we should attempt to get it in to FF3. This would be a huge help to keep the internet open by promoting open standards for video at a very crucial state for video on the web. Ideally we would have had this in a release a year ago, but waiting another year or two I think would make it much harder for free codecs to get market share.

Yes, I know we're well past feature freeze, but I think this one is worth making an exception for. It speaks directly toward MoFos goal of promoting freedom and innovation on the internet.
Autor patche Chris Double nedávno zveřejnil nový testovací build Firefoxu s připravovanou podporou videa, který umožňuje např. kombinaci značky <video> s SVG. Vložené video tak lze v prohlížeči snadno posouvat, zvětšovat nebo natáčet. Pokud si nechcete výsledek vyzkoušet sami, podívejte se na ukázkové video.

Když jsem to viděl poprvé, vzpomněl jsem si na dvě přednášky. Přednášku Tomáše Metličky o budoucnosti Flashe a Adobe Air a přednášku Štěpána Bechyňovského o Silverlightu. Oba při prezentaci svých produktů totiž spustili nějakou grafikou nabitou ukázku a vítězně poznamenali něco ve smyslu: Tohle webový prohlížeč bez našeho pluginu nikdy umět nebude.

Když se dívám na ukázku (která mimochodem vznikla jako napodobení jednoho Silverlight dema), říkám si, jak dlouho to NIKDY ještě bude platit.

neděle 23. září 2007

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.

úterý 11. září 2007

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.