HTML 4 5 6...

HTML5.cz a překlad knihy Dive into HTML5

2011-09-23T00:22:00.001+02:00

Už to jsou 4 roky, co jsem začal tento blog. Tehdy jsem měl ještě na svědomí většinu českých textů o HTML5.

Čas poskočil, doba se změnila, auto se rozjelo a dnes existuje o HTML5 textů sice hromada, ale stále chybí místo obsahující informace, které by postačily ke zvládnutí základů a středně pokročilých možností HTML5.

Rád bych takové místo vytvořil a kde jinde než na doméně www.html5.cz (měl jsem to ostatně v plánu už před lety, ale pak do toho přišlo založení Zdrojáku a měl jsem hned jiné starosti).

Rozcestník a agregátor

První částí HTML5.cz bude rozcestník po českých hodnotných textech o HTML5 (když už to někdo napsal, tak ať to jde snadno najít). Ty zatím sbírám a přidávám.

A na titulní stránku jsem dal agregátor nedávno vydaných článků o HTML5. (Teď si trochu vymýšlím - není to žádný automatický agregátor, dávám je tam zatím ručně. Pokud byste měli něco naprogramovaného nebo odzkoušené nějaké open source řešení, rád uvítám vaši pomoc. Já zatím zkoumám, zda by to nešlo založit celé na Yahoo Pipes bez zbytečného programování.)

Překlad Dive into HTML5

Tou nejdůležitější částí je mít kompletní text, který byste si během několika dní přečetli od začátku do konce a mohli pak říct "Já už tomu HTML5 rozumím." Já mám za to, že takový text existuje, jedná se o knížku Dive into HTML5 od Marka Pilgrima. Text knihy je pod Creative Commons licencí, dokonce pod tou nejvolnější, pustil jsem se tedy do překladu do češtiny. Nejsem sice (zatím!) žádný velký překladatel, ale česky trochu umím, tu FCE zkoušku z angličtiny jsem taky dal a na Twitteru jsem našel pár kamarádek profesionálních překladatelek, které jsou ochotné občas poradit (zdravím! 8-), tak si myslím, že bych do jednoho roku ten překlad mohl dovést do přijatelné podoby.

Zda se výsledku chopí nějaké české nakladatelství a vydá ho v tištěné podobě, nebo tím výsledkem bude pouze web kniha.html5.cz (plus nějaký z ní vygenerovaný e-book) , to se ještě necháme překvapit.

Komunita, podpora a tak...

A jelikož výsledný překlad bude opět k dispozici pod Creative Commons licencí (můžete si ho klidně forknout na githubu podobně jako jsem ho Marku Pilgrimovi forknul já), nestydím se žádat o nějakou tu pomoc publika.

Tou nejlepší by byla pochopitelně přímá pomoc s překladem (kdyby si někdo chtěl vzít třeba celou jednu kapitolu knihy a do cca 2 měsíců ji přeložit, bylo by to krásné). Ale pomůže i prosté připomínkování překladu, hledání chyb, nekonzistencí a překlepů. A těch tam je zatím hromada, protože to zveřejňuju, jak to leží a běží, a většinu textu jsem popravdě zatím jen přeložil a ještě po sobě nečetl a nekontroloval.

Kdybyste chtěli, mám na to takový formulářík, všechno můžete hlásit tam.

Jirka Kosek na twitteru navrhnul:

"Můžeme si dát závody, jestli rychleji přeložíte Pilgrima nebo já zaktualizuji celé http://htmlguru.cz/ na HTML5."

Což o to, toho bych se nebál (Jirka tu svou knížku přepisuje už asi rok, tak mu to minimálně ještě jeden vydrží). Navíc ta Jirkova knížka je pro naprosté začátečníky v HTML (třeba pro ty, co se učí, co dělá značka <p>), zatímco Dive into HTM5 je pro ty, kdo klasické HTML znají a zajímají je ty extra novinky v HTML5.

Takže obě knížky tu mají své místo a nijak si nekonkurují. Otázka zní, oč by měl celý ten závod být. Protože bez onoho "oč" by to nebyl žádný pořádný závod. Poradíte?

Slidy: HTML5 APÍčka bez trička

2011-04-10T16:16:00.000+02:00

V březnu jsem na pražském setkání Drupalistů pod názvem HTML5 APÍčka bez trička přednášel o některých zajímavých částech HTML5, které můžete už dnes používat.

Původně jsem chtěl s publikací slidů počkat, až bude hotové video přednášky, ale co čert tomu nechtěl, video se pokazilo a nejspíš nebude.

Zájemcům můžu aspoň nabídnout slidy z přednášky. (A pokud vás snad absence videa mrzí a chtěli byste to vidět celé, tak prostě uspořádejte nějakou přednášecí akci a pozvěte mě 8-)

Celá akce byla originální drupalověmodrými muffiny, které jste na místě mohli ochutnat. Jejich autorky napsaly o setkání reportáž na LinuxEXPRESu, popis pečení a zápisky s cesty.

Ovace a kritiky loga HTML5: 3 dny po té

2011-01-21T11:11:00.001+01:00

Dnes je to třetí den od vydání loga HTML5. Logo tu není samo pro sebe, ale pro lidi, kteří ho budou používat. Jak bylo během prvních dnů od zveřejnění přijato?

Grafická podoba byla přivítána poměrně vřele. Vždy se najde nějaký brbla a může mít své (i oprávněné) důvody, proč se mu logo nelíbí (třeba ty, které jsem zmiňoval posledně). Nicméně při sledování reakcí na nové logo můžeme najít spíše nadšení.

Řada lidí v logu vidí supermana (náhoda nebo úmysl tvůrce?), což může přidat na jeho popularitě. Pro ty, kdo to jako já bez rady neviděli: Pětka připomíná slavné "S" a oranžový zužující se štít je vodítkem k červenožlutému Supermanovu logu.

Najdeme i další výklady. Snad nejvtipnější asociaci měl Jirka Bureš, který v logu vidí "odpadkový koš, do kterého padá HTML."

Jako úspěšné se ukázalo publikování grafických podkladů pod Creative Commons licencí, dokonce pod tou nejvolnější. Zcela dle pravidel můžete vytvářet grafické varianty, které se hodí pro váš web (např. barevně odlišené) nebo parodie jako HTML5 beer. Na zdraví!

Význam loga už nebyl přijat zdaleka tak pozitivně. Původní označení "pojďme pod HTML5 logo zastřešovat celou open web platformu, tedy i CSS3, SVG aj." se u lidí aktivně působících v oblasti webových standardů setkalo s vyloženým odporem. Pár příkladů:

W3C na to dnes zareagovalo poněkud diplomaticky. Sice otevřeně neřeklo, že by se původního pohledu provždy vzdalo, ale upravilo texty propagující logo včetně FAQ.

Takže zmizelo původní označení "The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.", místo něj se objevilo "This logo represents HTML5, the cornerstone for modern Web applications."

W3C nikde původní tvrzení neodvolalo, a to ostatně ani nejde, protože pověstný "džin byl již z láhve vypuštěn" a mezi pomocnými ikonami HTML5 loga najdeme i CSS3. Ovšem W3C aspoň nebude ono širší vnímání aktivně propagovat.

To byla velmi rozumná reakce (na W3C tuplem). Rychlý krok, který by zabrzdil základní nevoli a přitom nechával prostor pro další vývoj a diskusi.

Z tohoto pohledu se spuštění nového loga zatím zdá jako úspěch. Na nějaké počáteční spory se časem zapomene a ostatně ty nakonec pomohly informaci o novém logu rozšířit. Kdyby nové logo bylo od začátku bez problému, možná by se takového ohlasu ani nedočkalo.

Zdá se, že nové logo HTML5 s námi bude již navždy (nebo aspoň po velkou část naší profesionální kariéry). Smiřte se s tím a najděte si k němu cestu. Ať již se ho rozhodnete milovat či nenávidět.

HTML5 právě získalo od W3C své oficiální logo. A nejen to

2011-01-18T14:17:00.019+01:00

Je to tak. Nevím, kolik technologií má svá oficiální loga. Ovšem z HTML5 se stal buzzword zahrnující nejen vlastní technologii HTML5 (je to tak, s tím nikdo nic nenadělá). Proto v představení nepopisuje W3C HTML5 logo jako logo HTML5, nýbrž jako striking visual identity for the open web platform, v podrobnějším článku pak uvádí all-purpose banner for HTML5, CSS, SVG, WOFF, and other technologies that constitute an open web platform.

A takto to prosím vypadá:

Jsem z něj rozpačitý. Grafice vůbec nerozumím a nechám tedy jeho rozbor povolanějším, ovšem vadí mi porušení barevné identity. HTML5 bylo většinou spojované se zelenou barvou (podle WHATWG), možná i trochu s modrou barvou (podle W3C). Smysl oranžové mi uniká. Ale je to jen síla zvyku. Běžný webdesigner o WHATWG nic neví, o W3C se nezajímá, tak mu možná ta oranžová přijde akorát.

Logo vytvořil Michael Nieling, který důvod vzniku loga popisuje v rozhovoru.

As you're aware, the term HTML5 has taken on a life of its own; there has been significant confusion and debate both within the developer community and in the public at large as to what exactly HTML5 is when the term is used outside of simply referring to the spec itself.

A co víc. K hlavnímu logu Michale vytvořil i loga některých HTML5 technologií, např. offline storage, sémantika nebo CSS3.

Pozn.: Nedivte se, v širším smyslu slova se pod HTML5 dnes zařazuje i CSS3 a opakuji - je to tak a nikdo s tím nic nenadělá. Sám to tak někdy také používám (a ne, nestydím se za to 8-). Nyní se ovšem oficiálně i W3C přiklonilo k tomuto výkladu, čili od teď je zařazování CSS3 pod HTML5 zcela legitimní. Pravda, u standardizační organizace mě to trochu překvapilo. Nejsem si jistý, zda v tom nebudou mít časem sami zmatky. Dodnes totiž bylo jasné, když W3C řekne HTML5, tak tím vždy opravdu myslí HTML5. Od teď tím může jednou myslet HTML5 a podruhé zase CSS3. Bude veselo. 8-)

Na vlastní web si můžete nechat vygenerovat obrázek, který zahrnuje seznam HTML5 technologií, které používáte. V případě úplně všech technologií bude vypadat takto (jinak by byl kratší).

A nyní otázka. Poznáte, která z ikon znamená třeba CSS3 a která sémantiku? Já rozhodně ne. Snad jen multilmédia podle té filmové klapky bych dokázal poznat. Možná jim chce nechat nějaký čas a časem si na ně zvykneme (ikony a loga jsou o zvyku), ovšem zatím jsem dokonale zmaten.

W3C tímto zkouší navázat na propagační strategii, kterou dříve používalo u validátorů. Jen si vzpomeňte, kolik HTML valid a CSS valid ikon jste kdy kdo použili (nebo aspoň viděli). Nejsem si jist, zda se doba neposunula a zda se podoná strategie dnes ujme, ovšem proč ne, za pokus to stojí.

Můžete si také koupit trička či samolepky s logem.

Pozn: W3C se dlouhodobě topí v nedostatku finančních prostředků, což se mj. projevuje i na tom, jak dobře W3C funguje. Řeší se to řadu let. Nebo spíš moc neřeší 8-) Jedním z návrhů už poměrně dlouho jest, aby W3C spustilo nějaký e-shop, který by byl pomocným zdrojem příjmů. Tiše doufám, že prodej HTML5 triček by k tomu mohl být prvním krokem. Jediné, co mě na tom znervózňuje, je fakt, že vlastníkem domény html5shirt.com je autor loga a nikoliv W3C!!! Zajímalo by mě, zda z toho prodeje W3C opravdu něco bude mít - doufám, že jo.

Závěr: Hlas W3C není rozhodně silný jako před lety. Občas se musí ozvat, a to pořádně hlasitě, aby bylo slyšet. Vytvoření tohoto loga (resp. celé sady) je vlastně takovým zvoláním: "Pořád tu ještě jsme, stále dýcháme. Pořád ještě vytváříme standardy, nezapomeňte na nás."

Berte to tak. A přesto, že k logu (resp. celé sadě) mám dost připomínek, tak v zásadě tahle strategie je rozhodně dobrá a snad bude i úspěšná.

Další odkazy

Flash proti HTML5

2010-11-03T07:41:00.003+01:00

Tahle hra vypadá jako klasický Pong. Jen s tím rozdílem, že jedna část je vytvořena pomocí Flashe a ta druhá pomocí HTML5. Poznáte během hraní s jistotou, která je která? Nebo se obě chovají stejně? Pochopitelně aniž byste k tomu museli stránku zkoumat, pak by bylo vše hned jasné.

Zdroj: Mashable

Michael Mahemoff: Vytvářet software se nenaučíte jen čtením knížek (rozhovor)

2010-11-01T13:52:00.005+01:00

Michael Mahemoff pracuje v Googlu jako Chrome Developer Advocate. Řadu let píše pro Ajaxian a v roce 2006 napsal knihu Ajax Design Patterns. Je autorem užitečných nástrojů, např. ListOfTweets.com a také vtipného projeku IE6IsOlderThanYourGrandpa.com. Bloguje na Softwareas.com a tweetuje jako @mahemoff.

You can switch to English version.

Píšeš pro Ajaxian už pět let, takže detailně sleduješ dění v tomto oboru. Co považuješ za největší změny ve světě JavaScriptu a AJAXu za posledních pět let?

Byla tu hromada inkrementálních změn, prohlubovalo se například naše chápání JavaScriptu a objevovaly se knihovny a nástroje jako jQuery a Firebug, které vývojářům usnadňovaly život. Dalším přínosem bylo výrazné zlepšení výkonu. Ovšem tu zásadní post-ajaxovou změnu můžete vidět poslední dobou na nových schopnostech prohlížečů, tj. HTML5, CSS3 a příbuzných technologiích jako je třeba geolokace (které pro zjednodušení společně všechny označuji jako "HTML5"). Dříve nebylo možné pracovat s videem nebo pokročilou grafikou bez ohledu na to, jak dobří jste byli v JavaScriptu. Museli jste se uchýlit k používání pluginů, hacků a obezliček, abyste dosáhli schopností vyžadovaných u moderních aplikací. Dnes pro řadu z těchto schopností existují vyhrazená API definovaná jako otevřené standardy. Oproti předchozím technikám jsou obvykle rychlejší, bezpečnější a snazší pro vývojáře.

Michael přednáší na JSConf 2010 (Zdroj: Flickr)

Spolu se softwarovým inženýrstvím jsi studoval také psychologii. Jak jdou tyhle obory dohromady?

V řadě věcí. Tím obvyklým průnikem a fascinujícím tématem byla vždy umělá inteligence. Ovšem v minulých desetiletích se z převážně akademických vod vynořila User Experience a stala se klíčovým podoborem moderního softwarového vývoje. Všimněte si, že recenzenti dnes mezi faktory zařazují i uživatelskou přívětivost; lidé očekávají, že produkty budou intuitivní. Toho lze dosáhnout pouze s pochopením lidské psychologie, což znamená víc, než jen spekulování; psychologie je obor postavený na faktech.

Napsal jsi knihu Ajax Design Pattern, jak ses od blogování a programování dostal k napsání knihy?

Kniha vznikla na základě mého blogpostu na stejné téma. Bylo to krátce po té, co vznikl termín Ajax. Lidé byli nadšení, můj text zabodoval na těch správných webech (Delicious Popular apod.) a z O'Reilly mě požádali, abych o tom napsal knihu. Pokračoval jsem současně v blogování ukázek a v psaní textu knihy na wiki.

Pokud budu někdy psát další knihu, nejspíš se vyhnu používání wiki a budu se víc soustředit na blog, nebo aspoň na wiki s komentáři. Je to lepší, když žádáte o zpětnou vazbu. Lidé se totiž jen zřídka pouští do úprav dlouhých článků, které napsal jeden člověk. (A když už to učiní, jedná se v polovině případů o spam!)

Michael přednáší na JSConf 2010 (Zdroj: Flickr)

Nějakou dobu jsi se věnoval TiddlyWiki. To je poměrně kuriózní projekt. Co se ti na něm líbí? (Pozn.: TiddlyWiki je wiki distribuovaná jako jeden jediný HTML soubor.)

Pracoval jsem s TiddlyWiki v Osmosoftu, což je inovační skupina v BT, kterou vede tvůrce TiddlyWiki Jeremy Ruston. Ovšem o kód TiddlyWiki jsem se zajímal už dřív, když jsem psal Ajax Design Patterns. Rozhodně se nejedná o typický projekt. Rád jsem tehdy žertoval, že jako jeden z mála lidí na světě jsem placen, abych vytvářel webové aplikace běžící na protokolu "file:".

TiddlyWiki je v jádru tvořena jedním jediným souborem, který obsahuje veškerý kód HTML, kaskádové styly i JavaScript. To byla samo o sobě už tehdy inovativní myšlenka, ovšem co ji dělá stále výjimečnou je schopnost uložení aplikace na lokální disk bez použití rozšíření prohlížečů i bez offline storage API z HTML5. Je to možné pomocí Active X v IE, nativního API ve Firefoxu a v ostatních prohlížečích pomocí appletu v druhém souboru. Můžete tak snadno vytvářet perzistentní webové aplikace a dokonce i "guerilové" víceuživatelské aplikace pouhým umístěním HTML na sdílený disk.

Další cool vlastností je systém pluginů. Zatímco TiddlyWiky ve výchozím stavu slouží jako osobní wiki, můžete z ní snadno vytvořit blog, prezentaci nebo cokoliv jiného. Nahrál jsem screencast popisující, jak během 15 minut vytvořit fórum. Používám k tomu TiddlyWeb, protože se jedná o fórum hostované na serveru, ačkoliv bylo vyvinuto na protokolu "file:".

S Michaelem Mahemoffem se můžete osobně potkat 15. listopadu na hackathonu, den před GDD. (Na akci se navíc uvidíte celý den i se mnou, protože jsem mezi organizátory 8-)

Zajímá vás HTML5? Sestavte vývojářský tým a zkuste za 1 den naprogramovat užitečnou aplikaci. My vám k tomu dáme: prostor, občerstvení, připojení k internetu a podporu několika Googlích vývojářů v průběhu dne.

Serverovou část aplikace můžete vytvořit ve vašem oblíbeném jazyce. Klientská část musí využívat některých možností HTML5.

Pokud HTML5 zatím pořádně neovládáte, nezoufejte, pro přehled si projděte prezentaci na HTML5Rocs. Na místě budou vývojáři z Googlu (včetně Michaela), kteří vám budou celý den k dispozici a poradí vám.

Zaregistrujte se, těšíme se na vás.

Další informace najdete na Facebooku nebo Twitteru.

Hackathon pořádá GUG.cz v partnerství s Google, czu.gug.cz a Provozně ekonomickou fakultou ČZU.

Máš rád hackathony. Co považuješ za největší přínos hackathonů?

Některé hackathony jsem si zamiloval. Vytváření software má jako disciplína své silné i slabé stránky. A tou opravdu silnou stránkou je možnost vytvoření něčeho naprosto úžasného během jednoho jediného dne. Samozřejmě, řada lidí na hackathonech něco až tak dobrého nevytvoří, ale i tak aspoň něco vytváří a tím se hodně naučí.

Hackathony jsou oslavou toho úžasného, co se děje, když začneme den se zárodkem malého nápadu a skončíme ho předvedením hotového díla ostatním. A obsahuje i sociální přínos - navázání nových známostí, možnost pracovat s ostatními a učit se od sebe navzájem. A to v takové míře, jak účastníci chtějí. Někteří radši pracují samostatně - i to je v pořádku.

Navíc vytvářet software se nenaučíte jen čtením knížek nebo posloucháním. Můžeme se dohadovat, proč tomu tak je, ovšem většina vývojářů se shodne na tom, že k pochopení základů si musíte vyhrnout rukávy a pustit se do vlastního kódování. Hackathony jsou k tomu ideální prostředí, je to takové bezpečné místo, kde váš výstup není nijak kritický a máte řadu možností, jak vám může někdo poradit a poskytnout zpětnou vazbu.

Jaký byl ten nejdelší hackathon, kterého ses účastnil?

V BT jsme praktikovali agilní přístup a akce intenzivně probíhaly po tři dny. Snažili jsme se dát dohromady všechny investory projektu a získat pozornost uživatelů, takže jsme s nimi mohli pracovat a žádat je o testování vznikajícího díla. Ujasnili jsme si naše nápady a naplánovali další iteraci.

Nebylo to perfektní. Měl jsem občas pocit, že pro správnou vyváženost potřebujeme víc vývojářů, abychom mohli dělat akce, které se soustředí na tvorbu skutečných projektů a jejich prezentování na konci každého dne.

Někteří říkali, že tohle je způsob, jakým má software vznikat dennodenně - nemá se jednat o občasný velký třesk. Ovšem já myslím, že ve velkých mnohonárodních korporacích jsou akce typu "velký třesk" tím nejlepším realizovatelným způsobem. Většina z těchto akcí měla pro firmu opravdu přínos.

Takže v Osmosoftu jste pořádali firemní hackathony? Proč by měly firmy pořádat své vlastní hackathony?

Ano, byly velice efektivní a nakonec jsme je pořádali asi jednou měsíčně. Mám na to pěkné vzpomínky. Osmosoft měl řadu interních zákazníků a externích partnerů. Ráno jsme se sešli se zákazníkem - obvykle jich přišlo několik. Dohodli jsme se na uživatelských scénářích, jejich prioritách a začli jsme s hackováním. Obvykle tak hodina až dvě sprintu. Začínali jsme v 10 dopoledne a výsledek práce prezentovali v 7 večer. Mezitím byly sprinty, standup meetingy k synchronizování a naplánování dalšího sprintu. Pokud to šlo, po celou dobu jsme checkovali do GitHubu nebo podobného repozitáře a tweetovali jsme o celé akci. V plánu bylo nejen odprezentovat naši práci, ale také veřejně spustit vytvořenou webovou aplikaci (to se však často nepovedlo).

Musím zdůraznit dva důležité body. Za prvé, náš postup byl velmi rychlý, což naše zákazníky většinou překvapilo. Důvodem byl náš důraz na znovupoužívání - každý projekt byl nejen příležitostí pro vytvoření nové aplikace, ale současně také vytvoření série komponent, které jsme mohli použít v dalších projektech. Nešlo nám o velké enteprise vize, ale o vytvoření padesátiřádkového pluginu pro TiddlyWiki, který dělal něco užitečného. Mohl to být plugin pro komentáře, grafický editor nebo počítadlo slov.

Za druhé, otevřenost může být v kontextu společnosti tvořící nový produkt překvapující. Mohli jsme si to dovolit protože jsem stavěli framework na bázi pluginů. Osmosoft mohl jako tvůrce open source vytvářet open source komponenty a s tím i aplikaci, která z velké části na těchto komponentách stála. BT si ji mohla upravit pro své vlastní potřeby a stejně tak jakýkoliv jiný podnik (např. naši externí partneři). My jsme byli součástí BT a tak jsme jim nabízeli přímou podporu k úpravě aplikací. Ale ukázali jsme, že open source může i v případě velké společnosti fungovat a předvedli jsme přínosy hackathonů.

Letos na jaře jsi začal pracovat pro Google jako Chrome Developer Advocate. Jak ses k té práci dostal? Byl to tvůj nápad nebo tě Google oslovil?

Byl jsem osloven jednou osobou z Googlu a pak jsem už prošel klasickým přijímacím procesem.

Chrome podporuje rozšíření, podobně jako řada dalších prohlížečů. Ovšem každý prohlížeč obsahuje jinou implementaci. Nemělo by se rozhraní sjednotit, aby bylo možné jednou napsat rozšíření a spouštět je pak všude?

Obvykle se říká write once, run many, což je velkou výhodou samotného vývoje pro web. Stinnou stránkou je, že tím můžete předčasně zabrzdit inovační proces. Takový mechanismus rozšíření Firefoxu umožnil úžasné věci - třeba takový Firebug, ovšem pro běžného vývojáře je těžké v něm začít tvořit - zbyl tu prostor pro další zlepšování, bylo příliš brzo na standardizaci.

Dnes má Chrome pro rozšíření mechanismus, který je webovým vývojářům blízký, Mozilla má JetPack a Safari s Operou také podporují rozšíření. Doufejme, že lidé začnou kreslit Vennovy diagramy a hledat, co mají jednotlivé mechanismy společného. Ovšem jen v případě, že to nezastaví prohlížeče v dalších inovacích. Chrome třeba nedávno nabídl rozšířením možnost přidat se do kontextové nabídky; něco takového by nemělo být blokované standardizačním procesem.

Na kolika Google Developer Days přednášíš?

Přednášet budu na třech evropských GDD (v Mnichově, Moskvě a Praze), na každém budu mít dvě session: Google Chrome Extensions a HTML or Native for Mobile Development. Na té druhé budu společně s Android advokátem Retem Meierem.

Už jsi byl někdy v Praze nebo je to tvoje první návštěva? Na co se nejvíc těšíš?

V Praze jsem zatím ještě nebyl. Nejdůležitější je pro mě GUG akce před GDD. Česká republika má silnou vývojářskou komunitu, těším se na setkání s místními vývojáři a na to, s čím přijdou.

Děkuji za rozhovor

Otázky kladl Martin Hassman, odpovídal Michael Mahemoff.

A pokud vás myšlenka hackathonů zaujala, neváhejte a zaregistujte se na náš hackathon, který pořádáme 15. listopadu v Praze.

Michael Mahemoff: You can't just learn by reading or listening (interview)

2010-11-01T13:50:00.009+01:00

Michael Mahemoff works for Google as Chrome Developer Advocate. He has been writing for Ajaxian for many years and wrote Ajax Design Patterns for O'Reilly in 2006. He is the author of useful tools such as ListOfTweets.com and also a funny project, IE6IsOlderThanYourGrandpa.com . He blogs at Softwareas.com and tweets as @mahemoff.

Můžete si přečíst český překlad. There is Czech translation available.

You have been writing for Ajaxian five years already, so you watch this field very closely. What were the most important changes in JavaScript-and-AJAX-World during last five years from your point of view?

There have been plenty of incremental changes, like our understanding of JavaScript getting more sophisticated and the introduction of libraries and tools like jQuery and Firebug to make life easier for developers. We've also benefited from massive performance improvement. But I think the most disruptive change, post-Ajax, is what we've seen recently with the new capabilities of browsers, i.e., HTML5, CSS3, and related technologies such as Geolocation (all of which I collectively refer to as "HTML5" for the sake of convenience). No matter how fluent we became with JavaScript and the like, it was still not possible to do things like video and rich graphics. To achieve the kind of capabilities modern apps required, we had to resort to browser plugins, hacks, and workarounds. Now with HTML5, we have dedicated APIs for many of these capabilities, defined as open standards. Compared to the previous techniques, they are based on open standards and they are typically faster, more secure, more powerful, and easier for developers to work with.

Michael speaking at JSConf 2010 (from Flicker)

You studied Psychology in addition to Software Engineering. How do these subjects go together?

In many ways. Artificial intelligence has always been the obvious intersection and remains a fascinating topic. But over the past couple of decades, User Experience, has come to the fore and emerged from a rather academic niche into a key sub-discipline of modern software development. You see product reviews now which include User-Friendliness as a factor; people expect products to be intuitive. You can only do that with an appreciation of human psychology, which means more than just speculation; psychology is an evidence-based discipline.

You wrote book Ajax Design Pattern. How you got to writing book from blogging and programming?

The book was the product of a blog post on the same topic, where I got inspired to collect ideas after seeing the Ajax term coined. People got excited, it hit a few of the right sites (Delicious Popular, etc.), and O'Reilly approached me about writing a book. I continued blogging excerpts as well as writing the entire book on a wiki. If I write another book, I would probably avoid the wiki approach and concentrate more effort on the blog, or at least a wiki with comments. It's a better way to solicit community feedback as people will rarely make edits to a long article that is mostly one man's voice. (And when they do, it's spam half the time!)

Michael speaking at JSConf 2010 (from Flicker)

You spent some time working with TiddlyWiki. It is a little bit strange project,isn't it? What do you like on it?

Yes, I worked on TiddlyWiki at Osmosoft, an innovation group inside BT which is run by TiddlyWiki creator, Jeremy Ruston, though I actually pored into the code much earlier, when I was writing Ajax Design Patterns. It's definitely different - I like to joke I'm one of the few people in the world who got paid to make web apps that run off a "file" URI. TiddlyWiki, at its heart, is a Single Page App - it contains all HTML, CSS, and JavaScript in a single file. This alone was innovative when it was first created, but what really makes it stand apart is its ability to save to the local hard drive, without any browser extensions and without using HTML5 offline storage APIs. It's possible using ActiveX on IE, native Mozilla APIs on Firefox, and resorting to a second applet file on other browsers, and it means people can easily build persistent web apps and even make "guerilla" multi-user apps just by sticking an HTML file on a share drive. The other cool thing is the plugin system. While TiddlyWiki is by default a personal wiki, you can quickly turn it into a blog, slideshow, or anything else. I recorded a screencast showing how to build a forum in 15 minutes. It also uses TiddlyWeb, so the forum is actually fully hosted on a server, even though its developed on a file URI.

You can meet Michael Mahemoff on HTML5 hackathon, on 15th November in Prague, register please (Google Translate).

You like hackathons. What do you see as the biggest benefit of hackathons?

Loves me some hackathon. As a discipline, software has strengths and weaknesses, and a major strength is that you can produce something completely awesome in a single day. Or of course, many people won't do exactly that, but they'll still build something and learn a lot in the process. So hackathons are a celebration of this amazing thing we do, where we can start the day with a seed of an idea and end up with a concrete manifestation of the idea. It's going with the flow, fitting in with the nature of software development. There's also a social aspect as well, people making connections, working with each other, learning from each other. And it can be as much or as little as the attendees want - some prefer flying solo, and that's fine too. Something else about software is that you can't just learn by reading or listening. We can debate the reasons, but most developers would agree you can only grasp the concepts by rolling up your sleeves and hacking out real code. Hackathons are an ideal environment to do that, a safe place where the output is not critical and there are plenty of opportunities to get feedback and assistance.

What was the longest hackathon you participated in?

At BT, we had an agile hothouse concept where the events went for three intense days.The idea was to pull together all the project stakeholders and put real users at the centre of attention, so we could work with them and ask them to test our emerging work. We could spike ideas and come out with a plan for the next iteration. It wasn't perfect. I felt like we sometimes needed more coders to get the balance right, in an event that was heavily oriented around building real products and presenting them at the end of each day. Some also argued that it's how software should work every day, not just an occasional big bang, but I think in a complex multinational corporation, such "big bang" events are the best thing realistically. I felt the principle was sound and found most of these events to be good value for the company.

So in Osmosoft there were hackathons inside the company? Why should companies try out their own hackathons?

Yes, they were incredibly effective and we ended up running them about one a month, as Osmosoft had a wide range of internal customers and external partners. Fond memories! We'd meet the customer in the morning, usually several of them present. We'd agree on user stories and prioritise them, and then we'd get hacking. Typically an hour or two per sprint, running from 10am and presenting our work at 7pm. Between sprints, a standup meeting to sync up and plan the next sprint. Ideally, we'd be checking into GitHub or similar repo the whole time, and tweeting the event. The ultimate plan was to not only present our work, but also host the resulting web app publicly by end of play (not that it always happened in practice).

There are two important points here. Firstly, we could move very quickly, in a way that often surprised our customer. The reason was our emphasis on reuse - every new project was an opportunity to build not just a new app, but a series of components that could be used on other projects. Not grand enterprisey whitepaper visions, but a 50-line TiddlyWiki plugin that actually does something useful, today. It could be a comments plugin, a graphical editor, or a word counter. Secondly, the openness may be striking in the context of a company building new products. We could do this because we were building a plugin-based framework. Osmosoft, as an open source provider, would make the open source components and an app which is mostly just a composition of those components. BT could then come along and customise it to their own needs, just as any other enterprise (such as our external partners) could pick it up and use it too. Of course, in practice, we were part of BT and we would offer them direct support in customising and deploying the apps. But we showed open source can work for a big company, and we showed the benefits of a hackathon.

You started working for Google in spring this year as a Chrome Developer Advocate. How do you got this job? Was it your idea or have you been asked by Google?

I was invited to apply for the role by someone in Google and I then went through a standard interview process.

Chrome has support for extensions as many other browsers today. But every browser has different implementation. Doesn't make sense to create some cross-browser interface for browser extensions? To make possible for developers to write extension once and run everywhere?

The obvious upside is write once, run many; which is a huge benefit of web development in general. The downside is the risk of stifling innovation too early. While Firefox's extension mechanism has led to wonderful things like Firebug, it's also been difficult for everyday web developers to jump into and left opportunities for improvement, so it was too early to standardise on something like that. Now that Chrome has an extension framework that's easy for web developers to pick up and use, and Mozilla has JetPack, and Safari and Opera also have extension mechanisms, hopefully people will start to draw Venn diagrams and work out where we have common ground. But only if it doesn't stop browsers from continuing to innovate in this area. Chrome has recently introduced the ability for extension commands to appear in the context menu; that's one example of the kind of ongoing improvement that shouldn't be hindered by a standardisation process.

How many GDD do you visit this year as a speaker?

I will speak at the three European GDDs (Munich, Moscow, Prague), in two sessions at each: Google Chrome Extensions and HTML or Native for Mobile Development. The latter will be me alongside Android advocate Reto Meier, so it should be a lot of fun.

Have you ever been to Prague or is it your first visit? What are you most looking for?

I've not been to Prague, but looking forward to it. The best thing for me will be the pre-GDD GTUG event. Czech Republic clearly has a strong web development community, so I'm looking forward to meeting the local developers and seeing what they come up with.

Martin Hassman was interviewing Michael Mahemoff before his visit to Prague.

If you want to meet Michael at hackathon on 15th November, please register.

Nepoužívejte HTML5! Ještě ne! Prosí nás prý W3C

2010-10-07T08:48:00.001+02:00

Používáte HTML5? Tak toho nechte. Aspoň prozatím. Na HTML5 je ještě brzy! Zhruba v tomto smyslu vyznívá včerejší rozhovor InfoWorldu s Philippem Le Hégaret z W3C. Ten citují další a další média a začíná se šířit internetem. A spolu s ním se šíří nepochopení. Co nám to ten Philippe z W3C chce vlastně říct? A proč? Zkusím to vysvětlil. Po lopatě.

Není to nic nového. V zásadě se jedná o odlišný pohled na dokončení specifikací mezi těmi, kdo specifikaci tvoří, a těmi, kdo ji používají. Vraťme se o tři roky zpátky, kdy autor HTML5 Ian Hickson prohlásil, že HTML5 dokončí někdy roku 2022.

Celý svět si tehdy ťukal na čelo. Za patnáct let? Opravdu to nebude dřív hotové?

Ian reagoval ve smyslu: Vy to začnete používat mnohem dřív, ale pro nás to bude hotové až okolo 2022. (Podrobněji viz Jak je to s termínem dokončení HTML5? z 2007)

Měl pravdu. Uplynuly tři roky (žádných patnáct!) a zdá se, že HTML5 opravdu začneme používat. Někdo letos, jiný možná za rok či dva, ale v zásadě se jedná o dnešní záležitost. (Na řadě webů ho spokojeně používáme už nějaký ten pátek a možná o tom ani nevíme.)

Z HTML5 se stal buzzword značící pokrok a firmy se předvádějí v jeho skloňování na svých prezentacích.

Realita se ovšem nezměnila. K dokončení HTML5 opravdu bude třeba ještě řada let (možná těch 10), podobně jako dosud není dokončené CSS2. (Překvapeni? Ono ale opravdu není!) V tom spočívá ono odlišné chápání dokončených specifikací. A z tohoto pohledu má Philippe z W3C pravdu, když upozorňuje, že HTML5 není ještě hotové, že není ještě dost ready.

A vadí to něčemu? Může nastat problém?

Popravdě může. Nemusí, ale může. Při takovém rychlém postupu vpřed bez koukání vlevo vpravo se může objevit menší či větší problém. Tím nejznámějším a nejrozsáhlejším problémem, který v minulosti přesně z tohoto důvodu nastal, byl rozdvojený box model.

Kdo děláte weby už pár let, vzpomínáte na odlišný box model Internet Exploreru a ostatních prohlížečů? Drobné nedopatření, za které jeden viní Microsoft, druhý W3C, ale pravdou je, že se jednalo o oběť rychlého pokroku. Tahle "drobná procesní chybka" pak dobrých deset let iritovala nějaký ten milion webových vývojářů.

Podobné chyby s obdobně velkým dopadem můžou vzniknout i dnes. A to je to, co se nám Philippe z W3C snaží říct.

Ne nadarmo se říká, že pokrok si žádá oběti. Naštěstí dnes už jsme si zvykli záplatovat podobné problémy různými frameworky. Ono komu by vadilo, kdyby existovalo třeba 5 různých nekompatibilních API k HTML5, když by mohl používat jeden JS framework, který za něj ty rozdíly vyřeší?

Čili dá se říct, že dnešní doba je připravena podobným problémům čelit lépe, než doba před nějakými 10 lety.

Proto nezbývá než Philippovi do W3C vzkázat, že děkujeme za upozornění, ale my to prostě risknem.

Lesk a bída HTML5 videa

2010-09-12T12:12:00.003+02:00

Je to už pár let, co se v HTML5 objevil návrh značky pro video a jednotné rozhraní sloužící k jeho přehrávání (viz články s tagem video). Myšlence od začátku fandím, dává rozhodně smysl, je jen škoda, že se neobjevila o pár let dřív.

Každopádně od svého počátku byla přijímána se silnou skepsí. Je to pochopitelné. Pokud má naplno fungovat, bude třeba najít kodeky, které budou přítomny na všech platformách (od Windows po třeba takový iPhone), aby na nich šlo HTML5 video přehrávat.

V posledních dvou letech zájem o HTML5 video vzrostl. Není divu. Jeho implementace v prohlížečích se začaly množit a zatímco nad specifikací dokáže radostně pokyvovat jen pár odborníků, tak interaktivní videem bežícím v prohlížeči se pokochá snad každý.

S tím začla opadávat i ona skepse. Ne zcela právem. Mediální jásání nad každou HTML5 video novinkou a la HTML5 verze Youtube bylo tak velké, že se začlo zapomínat, že ten velký problém je ještě před námi. A hlavně, že není řešitelný na straně prohlížečů.

U prohlížečů bylo poměrně záhy (již od roku 2007) jasno, že společný kodek, který by vyhověl všem, neexistuje. To je problém, který výrobci prohlížečů sami vyřešit nemohou. Bylo nutné jej eskalovat dál. Na jiné pole. Mezi výrobce kodeků.

První pokus učinila asi Mozilla, když začala sponzorovat zlepšení kodeku OGG Theora, který ve Firefoxu používá. Ovšem naplno začala druhá (ta důležitá) fáze "boje" o jednotný kodek až letos.

Zprávy o opensourcování VP8 u Googlu nebo o odpuštění některých z poplatků za H.264, jsou projevem této druhé fáze. HTML5 video začalo být konečně tak zajímavé, že se jím už zabývali i výrobci kodeků. A hlavně možnost stát se tím standardizovaným kodekem (a tudíž v blízkém budoucnu možná i tím nejrozšířenějším kodekem na světě) musí být docela lákavá.

Tím není bitva u konce, tím bitva teprve začíná. Všechny stávající kroky jsou takovým oťukáváním trhu a přípravou pro další vyjednávání.

Je to jako na šachovnici:

Jedna strana říká, že nemůže použít open source kodek OGG Theora pro obavu ze skrytých patentů. (Patová situace.) Druhá strana se praští přes kapsu a opensourcuje další kodek. (A vyjednávání může pokračovat.)

Nebo:

Jedna strana říká, že nemůže použít H.264 pro problémy s placeným licencováním. (Opět patová situace.) Druhá strana upraví podmínky tak, aby aspoň částečně uvolnila poplatky. (Opět posun pro další vyjednávání.)

To všechno jsou ale tahy rozehrávající partii. Jak ta proběhne, kdo bude vítěz, nelze zatím tušit. Ostatně dosud ani neznáme jména všech hráčů u téhle partie, připojit se může kdokoliv.

Ač HTML5 videu fandím, nepočítám, že by tahle partie o jednotné kodeky na webu mohla být dohrána v nejbližších 2-3 letech. Jsme na začátku, všechny karty nebyly ještě odhaleny.

Pevně věřím, že k nalezení jednotného kodeku nakonec dojde, protože teď si již snad všichni plně uvědomují potřebu takového jednotného kodeku. A tam, kde je potřeba, tam se i jednoho dne najde řešení.

Nicméně boj o jednotný HTML5 kodek nebude ani tak blesková bitva, jako spíš zdlouhavá zákopová válka. A jsme teprve na jejím začátku. Přes všechny zprávy o pokroku bychom si tohle měli uvědomit.

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

2010-06-24T13:13:00.006+02:00

Č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.

Internet Explorer 9 podporuje canvas. I s akcelerací

2010-06-24T08:04:00.008+02:00

BREAKING NEWS - Když jsem na podzim psal "investigativní" článek o tom, co vše se nejspíš objeví v Internet Exploreru 9, dávalo mi mé okolí najevo svou velkou skepsi. Uplynulo půl roku, nějakých 80% z něj se již splnilo a já pomalu přemýšlím, zda jsem neměl být na podzim nakonec odvážnější.

Dnes je již jasné, že IE9 bude obsahovat canvas. A jelikož je výstup IE9 hardwarově akcelerovaný, bude i tento canvas akcelerovaný (a tedy možná i pekelně rychlý).

Oznámil to Microsoft v posledním blogpostu.

Canvas - všechno, co umí (třeba i Wolfenstein v JavaScriptu a další), co bylo v IE6 - IE8 nutné emulovat JavaScriptem a tudiž bylo pekelně pomalé, bude v IE9 pekelně rychlé.

Další velký skok ve vývoji webu!! Mnohem větší než třeba lepší podpora selektorů nebo vyřešení CSS renderovacích chyb. Ty totiž byly sice nadmíru otravné, ale dalo se s nimi žít (a dlouhé roky jsme s nimi žili), zato canvas otevírá webovým aplikacím celou novou dimenzi.

A nejedná se zdaleka jen o hrátky typu Doom v prohlížeči, ale i takové plnohodnotné vývojářské IDE v prohlížeči nebo o nástroje, které zásadně překročují omezení dnešního boxmodelu v prohlížečích - co třeba takové "zaoblené" obtékání obrázků? A miliony dalších použití, které nás zatím vůbec nenapadly.

Jasně na rozšíření IE9 si ještě pár let počkáme, ale přesto dnešním dnem nastala změna. Do teď řada lidí k canvasu přistupovala jako k něčemu, co IE nikdy nebude podporovat, tudíž to v něm nikdy nebude pořádně fungovat a když, tak děsně pomalu pomocí JS emulace. Dnes lze k canvasu přistupovat jako k něčemu, co v fungovat bude a pořádně a stejně rychle jako v jiných prohlížečích a je jen otázkou času, kdy k tomu dojde. Pokud jste dosud canvas striktně ignorovali, možná stojí za to o něm od teď začít aspoň lehce uvažovat.

BTW Možnosti canvasu si můžete sami vyzkoušet v nové ukázkové verzi IE9. Já si to nemám teď, kde vyzkoušet, ale pokud budete mít tu možnost vy, zkuste, jak v něm ty nejznámější canvasové projekty a dejte mi prosím vědět.

Související

Google spouští HTML5Rocks

2010-06-22T22:48:00.005+02:00

Google dnes spustil nový web s názvem HTML5Rocks. Najdete na něm tutoriály pro základní stavební kameny HTML5. Bude se jednat o skvělý doplněk již dříve existujícího webu HTML5 Doctor.

A mimo jiné právě teď vychází kniha HTML5 for Web Designers. Pokud vím, tak vůbec první kniha zaměřená na HTML5. Její autor Jeremy Keith je poměrně známý (a má za sebou již pár knih). Jsem zvědav na první recenze.

Jaká byla XMLPrague 2010 z pohledu webaře

2010-03-16T16:40:00.002+01:00

XML Prague je jedna z těch mezinárodních konferencí, o kterých se ví víc ve světě než u nás. Předpokládám, že většina čtenářů tohoto blogu na XML Prague nikdy nebyla a možná o ní ani neslyšela. Ovšem vzhledem k tomu, jakou má XML Prague dlouhou tradici a jací významní lidé z oboru na ni jezdí, jedná se o jednu z nejvýznamnějších (možná vůbec nejvýznamnější) takových konferencí v ČR.

O XML se sice nezajímám moc do hloubky, přesto mě XML Prague zlákala, a tak jsem se nenápadně vetřel mezi všechny ty XML experty, kteří si o tomto víkendu dali v Praze sraz. Byli tu lidé ovlivňující budoucnost XML, ať již pod křídly W3C nebo ISO či OASIS.

Program byl silně odborný a úzce zaměřený. Z témat mě zaujalo např.:

Streaming in XSLT 2.1 - takové průtokové použití XSLT bez nutnosti načtení celého dokumentu do paměti

A Time Machine for XML - neboli časoprostorové procházení XML dokumentem. Klasický XML je de facto dvourozměrný (můžeme jím procházet svisle po ose rodič-potomek nebo vodorovně po ose sourozenců), pokud vezmeme v úvahu časovou historii dokumentu (čili jeho starší verze budeme uchovávat), není problém přidat osu třetí - časovou a procházet jí stejnými prostředky, jakými procházíme zmíněné dvě osy. Je to moc hezký nápad, zájemcům přikládám podrobnější článek.

XQuery in the Browser - je projekt, který přidává do prohlížečů prostřednictvím pluginu podporu XQuery jakožto skriptovacího jazyka. Můžete v něm pak programovat stejně jako v JavaScriptu (ukázka). Ač je to zajímavá myšlenka, mě se ten zápis vůbec nelíbí. Na druhou stranu autorovi projektu se zase vůbec nelíbí JavaScript (resp. přiznal, že ho vlastně moc neumí) - ale to mu nemůžu zazlívat, jsme holt oba z "opačné polokoule". (Ostatně jakási nechuť k dnešnímu webařskému světu byla cítit snad z celé konference.)

Future of XML at W3C - byla řeč zaměstnance W3C, jejíž základní myšlenkou bylo "Future is mutable" a "nebojte se zapojit do W3C a spoluovlivňovat další vývoj".

Multimedia XML - byla vlastně jediná webařská přednáška celé konference. Robin Berjon na ní ukazoval některé pěkné možnosti CSS3 a HTML5. Z publika byla ovšem cítit tak trochu nechuť. Svět prohlížečů ve světě XML moc neletí.

O rozevření nůžek mezi světem XML a světem webu vím léta, ale tady jsem si ho prvně pořádně vychutnal. Do budoucna se budu držet předsevzetí "Nikomu, kdo pracuje s XML nevěř." Což je docela praktické a člověk si tím ušetří problémy.

Tím nemyslím, že by ve světě XML nebyly zajímavě věci. Jsou a moc! Viz třeba témata výše. Ale tvoří je lidé, kteří dnešnímu webu a jeho filosofii nejenže nerozumí, ale často s ní bytostně nesouhlasí a nemají ji moc rádi. Proto ne každý jejich výtvor půjde ve světě dnešního webu elegantně a lehce aplikovat (ačkoliv v "jejich" XML světě bude samozřejmě skvělý). Ale to by bylo na dlouhou debatu, vraťme se ke XMLPrague.

Konference se mi moc líbila. Je pěkné jednou za čas vedle konferencí, na které jsme v Praze zvyklí, navštívit pro změnu konferenci, kde jsou lidé světového formátu, kteří ovlivnili minulost nebo ovlivňující budoucnost svého oboru.

Bylo skvělé, že konference šla sledovat online v přímém přenosu. Navíc kromě sledování #xmlprague na Twitteru bylo možné si sednout do virtuální twitter posluchárny (obrázek níže) a vidět, kdo další konferenci také právě sleduje. (Mohli jste i pomocí smajlíku vyjadřovat svou aktuální náladu, ale to prakticky nikdo nepoužíval.)

Dobrým nápadem byla i soutěž o nejlepší tweet se značkou #xmlprague, za který byla udělena poukázka na nějakých 300 dolarů do prodejen Applu. (A že se během konference twitterující skutečně snažili!)

Díky organizátorům za pěknou konferenci. A čtenářům, kteří se o XML tak trochu také zajímají doporučuji se příště na XML Prague podívat, když ne jinak, tak aspoň pomocí online přenosu.

A na závěr fotky z konference, do kterých jsem také trošku přispěl:

Vyšla další verze HTML5 - tentokrát přehlednější

2010-03-05T08:25:00.000+01:00

Včera vydalo W3C další pracovní verzi specifikace HTML5. Je rozdělena do několika dokumentů a na své si tentorkát přijdou i ti, kdo se v předchozích dokumentech nevyznali.

HTML: The Markup Language - přehled značek HTML5 se zdůrazněním změn oproti HTML4 (novinka - asi první dokument, po kterém sáhne běžný kodér)
HTML5 differences from HTML4 - podrobný soupis rozdílů HTML4 a 5
HTML5 - vlastní specifikace (nejdelší dokument)
HTML Canvas 2D Context - původně součást HTML5 spec. o značce canvas, vyčleněná do separátního dokumentu
HTML Microdata - separátní dokument o mikrodatech (vyčleněný podobně jako canvas)
HTML+RDFa - separátní dokument o používání RDFa v HTML5

Dodatek Additional Requirements for Bidi in HTML v našich končinách již tolik zajímavý není.

Jak se pracovní skupině pro HTML daří?

Já myslím, že docela dobře. Od roku 2007, kdy byla založena a kdy vznikl i tento blog, se udělalo hodně práce. HTML5 za tu dobu přestalo být suchou teorií, které nikdo nevěří. Začíná být používáno a skloňováno ve všech pádech, není snad prohlížeče, který by nějakou rozumnou část HTML5 neimplementoval. Snad všichni si dnes již uvědomili, že HTML5 je budoucnost (a de facto už i přítomnost).

Věci, které se od začátku jevily jako nesmyslné, se ukázaly jako nesmyslné. Pracovní skupina byla např. založena s plánem do prosince roku 2010 (to už je za dveřmi), do kterého mělo být HTML5 kompletně hotovo (i s referenčními implementacemi v prohlížečích!!). Nevěřil tomu snad nikdo (ani členové HTML WG), ale v zakládací listině to tak stálo. Do konce roku bude proto muset W3C nějak schválit pokračování činnosti HTML WG a stanovit další termíny. To jsou ale spíš byrokratické věci, které nás tolik nezajímají. Vlastnímu HTML5 se daří.

DailyMotion je další videoserver používající HTML5 a má zajímavé efekty

2010-01-26T18:30:00.003+01:00

DailyMotion je videoserver, kterému se občas přezdívá francouzský YouTube. (Uhodli jste jste správně - DailyMotion sídlí v Paříži.)

Když jsem zmínil nedávné spuštění HTML5 verze YouTube a HTML5 verze Vimea, nesmím zapomenout zmínit HTML5 verzi DailyMotion.

DailyMotion je u nás málo známý, o to víc je ale jeho HTML5 verze zajímavější.

Tou první zajímavostí je, že ačkoliv HTML5 verze YouTube a Vimea běží od letošního ledna, DailyMotion přináší HTML5 verzi již od května loňského roku (oficiální oznámení).

Tou druhou zajímavostí je, že zatímco YouTube a Vimeo používají H.264 (což dává smysl, protože v tomto formátu mají - dle dostupných informací - videa uložena), tak DailyMotion nabízí videa ve formátu Ogg Theora a můžete si je tudíž pouštět ve Firefoxu 3.5+.

Do HTML5 verze není třeba DailyMotion nijak přepínat. Pouze místo na www.dailymotion.com stačí zajít na openvideo.dailymotion.com.

Ovšem to nejzajímavější jsou experimenty, které DailyMotion na videech provádí. Zatím je můžete vidět jen na demo stránce - najdete je v menu vlevo od videa.

Kromě otáčení videa nebo vytváření fotogalerie z běžícího videa, najdete i klasické filtry jako je rozmazání nebo edge-detection (za běhu videa pomocí JavaScriptu v prohlížeči). V téhle podobě nemají velký praktický smysl, jsou zde jako ukázka možností a možná že i předzvěst budoucnosti.

Video na webu často chápeme jako neměnné a pevně dané, jenže ono je součástí stránky a lze s ním manipulovat. DailyMotion to svým experimentem dobře ukazuje. Navíc ukazuje, že manipulace s videem pomocí JavaScriptu nejsou nereálné. Vzpomeňte, že ještě takové dva, tři roky zpátky bychom tomu asi nikdo nevěřili. Dnes už věřit můžeme. Možná to ještě neběží tak rychle, jak bychom si přáli, ale je to hodně blízko.

Uvidíme, zda jednou nějaký videoserver přijde na to, jak takových možností využít i pro normálního uživatele.

BTW Problém s kodekem stále zůstává. DailyMotion si v HTML5 podobě pustíte jen ve Firefoxu 3.5. Údajně si ho snad můžete pustit i v Safari, pokud máte do QuickTime plugin přidávající podporu OGG (pokud byste s tím někdo měli zkušenost, dejte mi prosím vědět).

UPDATE: Daily Motion si navíc spustíte nejen ve Firefox 3.5, ale i v Chrome nebo Safari (pro něj posílají speciálně překódovanou verzi videa).

Už i Vimeo experimentuje s HTML5 videem

2010-01-22T10:44:00.005+01:00

Včera jsem psal o spuštění HTML5 verze YouTube, dnes můžu přidat další videoserver.

Vimeo neváhalo a krátce po oznámení HTML5 na YouTube přišlo s vlastním oznámením. I videa na Vimeu si nyní můžete přehrávat bez Flashe, jen za pomoci technologie HTML5 (značka <video>). Stačí otevřít jakékoliv video a zvolit odkaz "Switch to HTML5 player" napravo dole od něj.

Omezení jsou stejná jako na YouTube, musíte mít prohlížeč Google Chrome nebo Safari a nefunguje přehrávání videa ve fullscreenu.

Autoři Vimea zdůrazňují, že se zatím jedná jen o beta test. Přesto obsahuje jednu výhodu, kterou základní Flash přehrávač Vimea nemá. V HTML5 verzi můžete ve videu bez problému a celkem plynule přeskakovat dopředu i do dosud nestažených částí videa. To Flash přehrávač Vimea neumí, u něj je vždy nutné počkat na postupné stažení videa.

Google spouští HTML5 verzi YouTube. Bez reklam.

2010-01-21T08:40:00.003+01:00

Google včera oznámil spuštění verze YouTube používající možnosti přehrávání videa HTML5. Vedlejším efektem je, že se vám při přehrávání videa nezobrazují reklamy.

Nové značce <video> z HTML5 se věnuji od počátku tohoto blogu, můžete zde tak snadno najít téměř celou její historii. Detailnější popis najdete v příspěvcích Zkoušíme audio a video v Safari a Ukázka podpory videa ve Firefoxu 3.1.

HTML5 variantu YouTube si můžete aktivovat na stránce http://www.youtube.com/html5 Podporovány jsou pouze prohlížeče Google Chrome a Safari (Firefox sice HTML5 video umí, ale neumí kodek, ve kterém jsou videa YouTubu - tuším se jedná o H.264).

Po přepnutí můžete používat YouTube stejně jako dřív, s tím že se vám videa místo ve Flashovém přehrávači budou přehrávat přímo v HTML; zkuste si to na libovolném videu. Na některých stránkách se mi i přesto videa přehrávala ve Flashi (např. na stránkách s uživatelskými profily nebo u embedovaného videa na webech třetích stran).

Jediným omezením, na které jsem narazil, je absence fullscreenu. Tu totiž Chrome ani Safari nemají, v tuto chvíli ji podporuje asi jenom Firefox.

Závěr

HTML5 verze YouTube je (až na onen chybějící fullscreen) použitelná a můžete si ji bez obav sami zapnout, ať již jen na zkoušku nebo na trvalo.

Jedná se o ukázku dalšího mezníku, který technologie ze sbírky HTML5 dosahují. Je to ovšem ukázka omezená - verze YouTube, která by fungovala pomocí HTML5 v každém prohlížeči, se totiž jen tak nedočkáme. Problémem je zatím neexistující jednotný kodek, který by byl schopen splnit požadavky všech výrobců prohlížečů. Ovšem podobné snahy jako je HTML5 verze YouTube nebo ThePiratBay v HTML5 mohou hledání jednotného kodeku akcelerovat.

K čemu bude magická značka device

2010-01-19T08:08:00.001+01:00

Bez přístupu webových stránek k webkameře a mikrofonu si budoucnost webu dnes už asi nemůžeme představit. Byl by třeba i bez rostoucích trendů typu rozšířená realita (augmented reality), s nimi je zapotřebí dvojnásob.

Nápady, jak takový přístup zařídit, nejsou nové, ovšem teprve nedávno se začalo pracovat na standardním řešení pod hlavičkou HTML5.

A proto vznikla značka <device>. Jedná se o abstraktní rozhraní pro přístup k lokálním zařízením. Takovým zařízením může být webkamera (ale nejen ona). Značka device zajistí jen přístup k datům, nikoliv jejich výstup ani zpracování, k tomu využije napojení na některou další technologii. Takový zápis:

<device type="media" onchange="update(this.data)">

umožní uživateli zapnout kameru (jedná se o akci, kterou musí uživatel potvrdit), přičemž vlastní výstup v tomto případě směřuje do značky video:

<video autoplay></video>
<script>
function update(stream) {
document.getElementsByTagName('video')[0].src = stream.URL;
}
</script>

(Příklad pochází ze specifikace.)

To není vše, obsah kamery by nemusel být jen vykreslován, mohl by být zpracováván a pomocí canvasu upravován (např. pro vytvoření zmíněné rozšířené reality) a v případě napojení streamu na technologii Web Sockets může být stream videa zasílán do internetu (např. pro tvorbu videokonferencí - příklad pochází z blogu WHATWG).

Celý návrh je zatím jen první myšlenkový draft a jak to u podobných případů bývá, může před svou realizací projít velkými změnami nebo být zcela zrušen.

Mé poznámky:

Nejsem si jist, zda potřebujeme mít HTML značku <device>, nepostačilo by pouze javascriptové rozhraní? Ale je možné, že značka má vytvořit nějaké UI pro výzvu uživateli (podobně jako ji tvoří třeba <input type="file">), pak by dávalo umístění do dokumentu smysl.
Ptám se samozřejmě i sám sebe, zda potřebujeme <device>, když lze podobný výsledek dosáhnout ve Flashi. A hned si odpovídám, že potřebujeme. Protože zapsání značky <device> spolu s několika řádky JavaScriptu bude pro klasického webového vývojáře prostě neporovnatelně jednodušší, než projít kompilačním procesem Flashe, resp. se jej vůbec naučit. V tomhle Flashi trochu ujíždí vlak. Obsahuje sice zajímavé technologie, ale nedokáže je rozumně zpřístupnit webovým vývojářům formou, na jakou jsou zvyklí. Pokud Web dokáže nabídnout technologie stejného kalibru (to se mu zatím nedaří, ale směřuje k tomu poměrně dobře), bude muset Flash nabídnout něco jiného, čím by zaujal.

O HTML5 zpíval už Bob Dylan (video uvnitř)

2010-01-07T17:45:00.003+01:00

Možná tu píseň znáte ve verzi The Times They Are A-Changin'. Její méně známá verze ovšem zpívá o změnách v HTML5.

Poslechněte si ji v interpretaci Daniela Davise z Opery. Nemá sice tak pěkný hlas jako Bob Dylan, ale zas pěkně hraje na tu malou kytaru, které se správně říká ukulele.

Anebo trochu živější interpretaci v podání Bruce Lawsona (rovněž z Opery!):

Text v sobě skrývá mnoho pravdy ze standardizačního prostředí.

HTML5 – It is a Changin’

by Jeffrey G. Allen

Come gather ’round coders
wherever you roam
And admit that internet
Around you has grown
And accept that soon
A new spec will stand on its own.
If your skills to you
Are worth savin’
Then you better starting learnin’
Or you’ll sink like a stone
For HTML5 it is a-changin’.

Come designers and developers
who prophesize with your blog
And keep your mind wide
this chance won’t come again
And don’t speak to soon
For the spec is still in spin
And there’s no telling who
will be recodin’.
For the early adopter now
Will be later to win
For HTML5 it is a-changin’.

Come senators, congressmen
Please heed the call
Don’t sit on your thumbs
In the gathering hall
for he that gets lost
will be he who has stalled
There’s a spec in the works
And it’s changin’.
It’ll soon trim down your code
And add meanin’
For HTML 5 it is a-changin’.

Come mothers and fathers
Throughout the land
Learn to use content filters
And help to fight spam
Your sons and your daughters
Have gone mobile
And you’re old ways of surfing
is rapidly changin’.
Please get off the new one
If you can’t understand
For HTML 5 it is a changin’.

The spec it is out
It is Working Draft
The current one now
will later be past
As the new one
will venture to last
The spec is
rapidly changin’
And the current one now
will later be last
for HTML5 it is a changin’.

Po Internetu ovšem kolují rozmanité varianty, např.

Come Zeldman and Meyer
Malarkey and Mols
Let your songs of web standards
Ring in the halls.
And the lessons you teach
disseminate to one and all.
For the web that you now know
is not what you knew
For HTML 5 it is a changin’.

nebo

Mozilla and Safari,
Opera and IE,
HTML 5 needs your help
To be all it can be,
Wide browser support
Would help tremendously
And don’t forget about support for CSS3
HTML 5 It is a changin’

Na tento úžasný šlágr upozornila Molly E. Holzschlag.

Nedalo mi to a vzpomněl jsem si i na svůj HTML5 trailer, který jsem před lety vytvořil experimentuje s videem.

Řešení včerejší hádanky. Podívejme, jak jste si vedli

2010-01-06T07:30:00.001+01:00

Včera jsem vám dal hádanku, dnes předvedu řešení. Ať víte, zda můžete skákat radostí nebo ne. BTW přišlo mi cca 100 odpovědí, to je hezké.

Připomenu zadání. Stránku http://id.annevankesteren.nl/ tvoří jednoduchý kód (viz obrázek níže), ale přesto výsledná podoba stránky odporuje zdravému webdesignerskému rozumu, např. je má černé pozadí, a barevné písmo, ačkoliv zdrojový kód žádné definice barev neobsahuje. Vaším úkolem bylo určit, čím to je.

Napřed tu špatnou odpověď: Stránka obsahuje SVG, které je zodpovědné za ony grafické změny.

Pokud jste takhle odpověděli, nechali jste se pěkně nachytat. Stránka sice obsahuje SVG obrázek, ten ovšem obsahuje pouze logo OpenID:
Mohli jste si to ověřit buď dešifrováním onoho SVG souboru, který obsahuje dvě vyplněné cesty (s dešifrováním pomůže tutorial), nebo i jeho pouhým zobrazením v prohlížeči. Jak prosté milý Watsone!

A jaká je správná odpověď? V hlavičce HTTP se vyskytuje položka Link: <fancy.css>; rel=stylesheet a za design stránky je zodpovědný stylopis fancy.css.

Položka Link v hlavičce HTTP je alternativním způsobem pro přidružení stylopisu ke stránce a funguje analogicky jako značka LINK v hlavičce HTML.

Tento mechanismus se běžně nepoužívá (nepodporují jej všechny prohlížeče). Je zmiňován ve specifikaci HTML4.01, v minulosti tu byla několikerá snaha jej začlenit i do specifikace HTTP, ale neúspěšně (podrobně celý proces najdete zdokumentovaný na wiki W3C).

BTW před rokem jsem o tomto mechanismu psal na Zdrojáku, když jsem jej ještě vedl.

Pozn.: Někdo z vás si všiml, že Firefox použije stylopis i pro zobrazení jeho samého (taková kuriozita: styl stylující sám sebe). Vypadá to sice moc hezky, ale jedná se evidentně o chybu prohlížeče.

Zhodnocení řešitelů

Výsledek hádanky dopadl dobře a moc mě potěšil. Řada z váš našla bez dlouhého zaváhání správnou odpověď.

Je zároveň vidět, jak dobré nástroje dokáží posílit generační zdatnost. Kdybychom stejnou hádanku zadali takové 4 roky nazpět, výsledné skóre by pravděpodobně tolik povzbudivé nebylo.

Nástroje jako jsou Firebug, Web Inspector a další nám pomáhají hravě vyřešit i problémy, se kterými jsme se dosud nesetkali. Odpovězte si sami, zda byste problém vyřešili (resp. rychle vyřešili, nebo zda vůbec vyřešili) v případě, že byste podobné nástroje neznali. A tím nemyslím jen to, že byste je neměli právě po ruce, ale kdybyste je neviděli nikdy v životě.

Tak na viděnou u nějaké další hádanky. Ostatně pokud víte o nějaké další, třeba i lepší, tak se určitě pochlubte.

Hádanka pro webdesignery a kodéry. Vyřešíte ji?

2010-01-05T15:33:00.007+01:00

Mám pro vás malou hádanku. Znáte to - takovou, kterou génius vyřeší na první pohled, inteligent za pár minut, polointeligent za hodinu a ostatní si nad ní můžou lámat hlavu třeba celý den.

Ukážu vám jednoduchou HTML stránku. Má primitivní kód, asi na deset řádek. Přesto se její podoba v prohlížeči zcela vymyká běžné webdesignerské logice. Vaším úkolem je zjistit proč. Proč stránka vypadá tak, jak vypadá.

Podotýkám, že problém není postaven na žádných tajných novinkách z HTML5 ani CSS3. Klidně ignorujte, že stránka má HTML5 doctype, fungovala by stejně i bez něj. Ona záhada nepoužívá nic, co přišlo později než staré dobré HTML4 z 1999. Nejedná se ani o fintu žádného prohlížeče - stránka skutečně má správně vypadat tak, jak vypadá.

Hádanka

Jedná se o stránku http://id.annevankesteren.nl/ a vaším úkolem je zjistit, proč vypadá jak vypadá, tj. proč má barevné písmo, pozadí, nebo text na dva řádky atd., ačkoliv běžná logika tvrdí opak.

Stránka by měla vypadat asi takhle:

Abyste ji takto viděli, použijte Firefox nebo Operu. Jakmile problém vyřešíte, poznáte proč. Ale znova opakuji, nejedná se o žádnou fintu prohlížeče, nýbrž opravdu jen o standardní chování.

~~Vaše odpovědi můžete psát do komentářů. Zatím je nechám neviditelné.~~

Řešení najdete v mém dalším příspěvku.

Opera 10.5 přinese lokální úložiště z HTML5

2009-12-22T16:16:00.001+01:00

Dnes byla představena preview verze Opery 10.5. Obsahuje řadu novinek, např. dlouho očekávaný JS engine Carakan. Z pohledu HTML5 přináší jednu důležitou novinku a tou je podpora lokálních úložišť. Přesněji řečeno všech typů lokálních datových úložišť (nástupce cookies), definovaných v HTML5.

Web Storage

Web Storage zahrnuje localStorage a sessionStorage a umožňuje ukládat data v jednoduché podobě klíč - hodnota. Implementace najdeme již prakticky ve všech prohlížečích. Opera byla posledním prohlížečem, na který se ještě čekalo. Odhaduji, že cca do dvou let by se toto úložiště mohlo začít bez problému používat i pro široké nasazení. V tuto chvíli je lze bezpečně používat pouze s pomocí emulačních triků, které zajistí uložení dat v prohlížečích dosud nepodporujících Web Storage.

Web SQL Database (SQL5)

Webové úložiště postavené na SQL (někdy přezdívané SQL5) je složitějším úložištěm, které obsahuje jednoduchou SQL databázi. Zatím bylo implementováno pouze ve WebKitu (Safari, iPhone, Chrome) a v Google Gears. Opera tak přináší jeho v pořadí třetí implementaci. Na použití tohoto úložiště na webu si pravděpodobně počkáme ještě řadu let.

Jeho implementace v Opeře tak bude zatím zajímavá spíše pro tvůrce aplikací (widgetů) postavených na platformě Opera. Až se podpora dostane i do mobilní verze Opery, získají mobilní widgety pěknou databázi.

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

2009-12-11T10:31:00.011+01:00

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

2009-12-11T08:58:00.013+01:00

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.

Neoficiální zprávy o Internet Exploreru 9. Na pořadu jsou SVG, CSS transformace i canvas

2009-11-22T19:30:00.000+01:00

Před pár dny Microsoft zveřejnil první informace o IE9. Pročetl jsem je a sepsal k tomu své poznámky. Moc toho zatím není. Weboví badatelé ovšem ví, když výrobci prohlížečů mlčí, je třeba zabrousit do veřejných archivů W3C. Novináři tam nechodí. Ovšem my tam můžeme najít zajímavé informace. Přinejmenším něco vytušit.

Začněme tedy pátrat! Dobrým startovním bodem je sledování mailů, které aktuálně zasílají lidé s Microsoftu. Toho využijeme.

Internet Explorer 9 a SVG

Bude IE9 podporovat SVG? Nevíme. Pokud ovšem spočteme počet mailů směřujících z Microsoftu do pracovní skupiny pro SVG, zjistíme, že počet mailů za tento podzim vydá za počet mailů odeslaných v celých předchozích šesti letech! Jeden z nich je přímo od člověka, který je členem IE týmu program managerem pro Layout a Rendering. Vesměs se jedná otázky dotýkající se implementace SVG. Zdá se, že Microsoft implementaci SVG minimálně zvažuje. Jsem moc zvědav, zda se to potvrdí, protože vektorová grafika je další důležitý mezník ve vývoji webu.

(BTW Microsoft byl i zlatým sponzorem konference SVG Open 2009. To jistě nebude náhoda.)

Internet Explorer a CSS

V pracovní skupině pro CSS je velmi živo (viz přehled mailů od Microsoftu ve veřejném mailing listu). Nejvíce mě zaujalo, že se Microsoft zajímá o CSS transformace (ty co znáte např. ze Safari, zej. na iPhone) a také o Multi-column layout, jednu z technik CSS3 rozšířujících schopnosti layoutu (popisuje ji Honza Sládek ve svém článku Budoucnost layoutů dle CSS3). I zde jsem byl potěšen.

Opět to neznamená, že Microsoft do IE9 tyto vlastnosti skutečně implementuje, ale jen tak pronic zanic se o ně nezajímá.

Internet Explorer 9 a canvas

I ve skupině pro HTML5 je živo (viz přehled mailů od Microsoftu), nejvíce mě zaujalo, že Microsoft se vážně zajímá o canvas. Natolik vážně, že ve vývojové verzi specifikace již najdete zástupce Microsoftu mezi jejími editory. To zároveň vzbudilo jistou nevoli (viz celé vlákno) a obavy, zda Microsoft nemůže canvas (v tuto dobu již implementovaný ve všech běžných prohlížečích) nějakým způsobem pozměnit.

Canvas je po SVG dalším prvkem, který může posunout vývoj webu v mnohém kupředu. Emulace canvasu pro IE již existují, ovšem jsou pomalé a nepodporují kompletně celé API. Plná podpora v IE9 by byl malý zázrak. Doufejme tedy, že implementace Microsoftu bude s ostatními prohlížeči kompatibilní a že ve specifikaci canvasu neudělá nějaké problematické změny.

Celkový závěr

V mém shrnutí oficiálních informací o IE9 jsem vyjádřil své přesvědčení, že IE9 bude podporovat mnohem víc webových standardů, než co zatím Microsoft představil, jinak bych nebyl s IE9 ani trochu spokojen. Po tomhle malém investigativním průzkumu jsem z tohoto neoficiálního přehledu poměrně potěšen.

Zdůrazňuji, že nic z výše uvedeného není oficiálně potvrzeno, ale vidím tu dobrou šanci, že se aspoň něco z toho v IE9 objeví.

To je ode mě vše. Pokud objevíte nějakou další zajímavost, budu moc vděčný, když mi dáte vědět.

WidgetPad - s HTML5 na mobilní zařízení

2009-10-11T21:09:00.005+02:00

Nemusí to být na první pohled jasné, ale HTML5 se snaží udělat z webu vhodnou platformu i pro aplikace běžící na mobilních zařízeních. Příklady takových "aplikací" napsaných v HTML5+CSS3+JS najdete na serveru WidgetPad.

WidgetPad ovšem není jen prostou kolekcí hotových aplikací, je především prostředím pro jejich vývoj. U každé aplikace (widgetu) tak najdete nejen tlačítko "View Source" (všechny publikované widgety jsou open source), tak možnost "Fork", čili vytvoření a vývoj vlastní kopii již existujícího widgetu.

Server je tak šikovný pro experimentování. Představte si, že narazíte na zajímavý widget a napadne vás, jak jej vylepšit. Stačí zvolit Fork a můžete rovnou začít. Server WidgetPad pak zajistí, aby vaši aplikaci uživatelé snadno našli. Hotový vývoj ve stylu Web2.0.

Více o WidgetPadu najdete např. v článku WidgetPad: Open-Source, Web-Based Environment for Mobile Developers.

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

2009-10-06T23:03:00.004+02:00

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í.

Úvod do HTML5 od Brada Neuberga

2009-09-23T10:01:00.002+02:00

Brada Neuberga si možná pamatujete jako přednášejícího z loňského Google Developer Day. Nedávno natočil video s úvodem do HTML5. Soustředí se v něm na několik zajímavostí HTML5:

canvas
video
database
web workers (javascriptová "vlákna")

Brad ve videu také zmiňuje Geolocation API, ale to do HTML5 nepatří. Zajímavé je, že na začátku chtěl Google Geolocation API do HTML5 prosadit, ale (poměrně oprávněně) byl tento požadavek odmítnut. Google následně pod křídly W3C založil samostatnou skupinu Geolocation Working Group, v rámci které se standard Geolocation API formuje.

Nicméně Google se od té doby nějak nezbavil spojení Geolocation API = HTML5 a prakticky vždy uvádí Geolocation API jako součást HTML5 a Brad (zaměstnanec Googlu) není výjimkou. Následně se toho chytají novináři, tuto chybu (nebo možná marketingový trik?) opisují a šíří dál.

Ono je to jedno. Webovým vývojářům pramálo záleží na tom, ve které specifikaci se která vlastnost nachází, důležité je jen to, zda funguje nebo ne. Uvádím to zde jen jako zajímavost pro ty, kdo se budou divit, proč některé zdroje vedou Geolocation API pod HTML5 a jiné samostatně. Pravdu mají ti druzí.

Zdroj: Ajaxian

Hyperland - když se Stopařův průvodce stává internetovou realitou

2009-09-16T17:30:00.005+02:00

Zhruba ve stejné době, kdy byly vytvářeny základní kameny Webu, vznikl i dokumentární film Hyperland, ve kterém Douglas Adams (jako autor scénáře i hlavní herec) představil svět, kde televize již není lineární, nudná a neinteraktivní, ale hypertextová, multimediální a interaktivní. Svět, který se velmi podobá Internetu (a zejména Webu), jak jej známe dnes.

V téměř hodinovém snímku z roku 1990 se mu podařilo představit možnosti, které počítače a internet brzy nabídnou, v rozsahu, o jakém se Douglasovi patrně snilo, když si představoval svého elektronického Průvodce po galaxii.

Ve filmu Hyperland najdete řadu zajímavých faktů, účinkuje v něm i otec hypertextu Ten Nelson nebo Hans Peter Brøndmo, tvůrce myšlenky micon (kontextových ikon uvnitř videí).

Ať jste online novinář nebo webdesigner, až budete mít chvilku čas, určitě se na celý Hyperland podívejte. Je zajímavé vidět, co vše bylo očekáváno před dvaceti lety. Film je dostupný online pomocí služby Google Video:

Google Video

HTML5 nepotřebuje Supermana, má totiž Superkamarády

2009-09-01T15:40:00.000+02:00

Vzpomínám, když se u nás před dvěma lety začalo psát o HTML5, vzbudilo to jistou nevoli. Lidi nebyli na něco takového připraveni. Navíc tvůrci HTML5 jsou sice dobrými autory specifikace, ale nejsou vždy právě nejlepšími prodavači svých názorů.

Než se situace trochu vyrovnala a komunikační šumy poněkud zklidnily, vzniklo pár prostestních skupin, pár parodujících komixů a velká řada kritizujících blogpostů. Asi nic překvapivého, o lecčems z toho jste nejpíš už slyšeli.

Nedávno se ovšem objevila aktivita s názvem HTML5 Super Friends. Je zajímavá zejména už jen proto, že za ní stojí Jeffrey Zeldman, který ještě nedávno HTML5 silně kritizoval.

Dnes v příspěvku Loving HTML5 říká:

Čím víc zkoumám HTML5, tím víc se mi líbí.

Stránka HTML5 Super Friends výslovně tvrdí, že HTML5 sice není dokonalé a dokonce i SuperFriendi by chtěli některé části změnit. Přesto plně vyjadřují podporu pro směr, kterým se HTML5 vydává.

A kdo že se pod maskou SuperFriendů skrývá? Jména nikoliv neznámá:

Pro úspěch webové technologie není důležité jen, aby s ní byli za jedno její autoři, W3C, výrobci prohlížečů, ale aby s ní časem byli za jedno i webdesigneři. V opačném případě by neměla šanci na úspěch. Ovšem když už má takové SuperFriends, není co řešit.

Mark Pilgrim píše knihu o HTML5. Je dostupná online

2009-08-27T10:55:00.000+02:00

Mark Pilgrim je grafoman, který píše moc pěkné knihy. Asi nejznámější je jeho Dive Into Python.

Nedávno začal psát knihu Dive Into HTML5. Bude celá dostupná online, v tuto chvíli je k dispozici první dokončená kapitola věnující se canvasu.

Pěkné je nejen grafické provedení připomínající knihy sázené na prvních knihtiscích, ale také autorský styl, který na nás čiší z celého textu, viz názvy kapitol: SELECT * FROM BROWSER WHERE 5 > 2 nebo Multimedia in a Flash (Without That Other Thing).

Už se těším, až bude kniha hotova a budu ji moct zrecenzovat.

Zdroj: Simon Willison

Změny v předsednictvu HTML WG

2009-08-26T17:45:00.002+02:00

Předsedové pracovní skupiny pro HTML WG se za poslední rok kompletně vyměnili. Zakládajícími předsedy před dvěma lety byli Dan Connolly (W3C) a Chris Wilson (Microsoft). Dan Connolly již dávno odstoupil a nahradil jej Sam Ruby (IBM), dnes dochází k další změně.

Chris již dříve oznámil svůj odchod z IE týmu a před chvílí k němu přidal i své odstoupení z předsednictví HTML WG. (Chris byl pro mnohé webové vývojáře ikonou téměř identickou s "modrým e", jelikož vystupoval za IE tým na mnoha konferencích. Málokdo již ví, že je jmenován v seznamu lidí, kteří nejvíce pomohli počátečnímu rozvoji webu.)

Krátce nato Tim Berners-Lee oznámil nástup hned dvou nových předsedů. Stávají se jimi Paul Cotton z Microsoftu (o tom slyším prvně) a Maciej Stachowiak z Apple (pokud čtete blog vývojářů WebKitu, tak Macieje určitě znáte).

Historicky se tak prvně mezi předsedy HTML WG objevuje člověk (Maciej), který je již roky členem WHATWG a stál u samého zrodu HTML5.

Dnešní příspěvek byl čistě administrativní, ale pokud chceme pochopit změny, které se ve vývoji (čehokoliv, nejen standardů) odehrávají, je nutné sledovat i přesuny lidí na důležitých pozicích, protože právě oni jsou často zdrojem těchto změn.

Viz také: Oficiální oznámení na W3C

IE tým zkoumá standardy. Pozdě, ale přece?

2009-08-09T09:40:00.001+02:00

Před dvěma dny zaslal Adrian Bateman (program manager pro IE, jeden z členů IE týmu, s kterými jsem se letos osobně setkal) relativně dlouhý seznam připomínek k HTML5, který sesbíral mezi členy IE týmu.

Vyjadřuje se k řadě míst HTML5 specifikace. Pro mě je zajímavé, že se vyjadřuje i k několika místům, která již byla v minulosti diskutována a jsou již víceméně považována za prodiskutovaná a hotová. Například: potřebujeme značku <nav>? A značky <header>, <footer>, <section>, <aside>?

Je samozřejmě dobře, že se IE tým ptá. Nejasnosti je třeba vyřešit, obzvlášť, když se jedná o tak důležitého implementátora. Přesto mě vzniklá situace trochu pobavila.

Microsoft byl v čele HTML WG již od adopce HTML5 (její předseda, Chris Wilson, je z Microsoftu). Přesto byl hlas Microsoftu za celé dva roky existence HTML WG ze všech prohlížečů ten nejslabší. Dokonce to teď skoro vypadá, že se o HTML5, až na několik výjimek, které implementovali v IE8, vlastně téměř nezajímali.

Je těžké se v takové chvíli zbavit dojmu, že zatímco ostatní prohlížeče jsou v HTML WG, aby pomohly s vývojem HTML5, tak Microsoft tam byl spíš "jen tak naoko", "aby tam byl", ale de facto jej vývoj příliš nezajímal.

Nyní se vzpamatoval a říká si, "tak, jak to s tím HTML5 vlastně vypadá?" a začne se přehrabovat v tom, co ostatní za ty roky vytvořili.

Nicméně vidím i jedno pozitivní poselství, které bychom neměli přehlédnout.

V Microsoftu teď rozvažují, jak bude vypadat IE9, co vše bude obsahovat a začali (konečně) pořádně uvažovat o implementaci HTML5. Do IE8 se dostalo jen několik narychlo uvařených střípků HTML5, které tam byly spíš jen proto, aby se mohlo říct, že IE8 podporuje část HTML5. V IE9 se ale třebas dočkáme implementace HTML5 srovnatelné s ostatními prohlížeči. Adrianův mail je pro mě takovou první indikací, že by k tomu mohlo dojít.

U CSS3 podobné indikace zatím nejsou, u SVG jen jedna a to velmi nejasná, když Chris Wilson v lednu na chatu prohlásil: "We have heard a strong request for SVG support".

IE se sice jen tak nezbaví nálepky prohlížeče, jehož vztah k webovým standardům je problematický (jen pomyslete - když necháte ostatní prohlížeče vytvářet nějakou specifikaci, pak přijdete k víceméně hotovému a začnete se jim v tom rýpat, tak je přinejmenším naštvete), přesto na tom pomalu, ale jistě pracuje.

Teď bychom se mohli sázet, zda ostatní prohlížeče v podpoře standardů dožene ve verze IE9, IE10 nebo nikdy. Já tipuji na jednu z prvních dvou možností.

Malá reorganizace HTML5 aneb spin-offs

2009-07-30T11:30:00.000+02:00

Poměrně dlouho se vedla debata, zda všechny části specifikace HTML5 do ní skutečně patří. Její editor Ian Hickson na rovinu přiznal, že je pro něj snazší starat se o jednu velkou specifikaci než o řadu menších, což je pro něj důvod, proč vše udržuje pohromadě.

Tlak na rozdělení do menších specifikací postupně sílil, a tak v této době dochází k vyčlenění (spin-off) několika částí HTML5 do samostatných specifikací, a to hlavně:

Web Storage (jednoduché úložiště klíč-hodnota rozšiřující cookies)
Web Database (plnohodnotná SQL databáze přezdívaná SQL storage nebo SQL5)
Server sent events (možnost přijímání událostí ze serveru)
Web Sockets (peer-to-peer komunikace mezi webovými prohlížeči)

Více viz plný přehled.

Můžete si všimnout, že jádra HTML5 se rozdělení nedotklo, jedná se opravdu jen o vyčlenění funkčních celků, které můžou existovat samostatně.

Zda bude tohle rozdělení ve výsledku dobré nebo ne ukáže čas. Na jednu stranu je rozhodně snazší orientovat se v několika menších dokumentech než v jednom velkém. Na druhou stranu cítím, že u takové vyčleněné specifikace spíš hrozí, že se na ni prostě zapomene, nikdo se jí nebude věnovat a ona umře a nedivil bych se, kdyby k tomu minimálně v některých případech došlo.

A na závěr z komunikačního hlediska je lepší mít všechny zmíněné vlastnosti označené hromadně nálepkou HTML5 než používat kryptografické názvy dílčích specifikací. Dodnes z toho těží snad všichni implementátoři včetně Microsoftu. Ovšem to je hlavně rétorický problém, který lze snadno oblafnout. Vždy je možné vyčleněné specifikace označit jako moduly HTML5.

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

2009-07-16T10:20:00.004+02:00

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.

Jak odchází XHTML2

2009-07-15T10:01:00.002+02:00

Dnes sérii článků o konci XHTML2 (viz 1, 2 a 3) rozšířím. Na blogu Shane McCarrona, jednoho z členů pracovní skupiny pro XHTML2, jsem našel zajímavou zpověď, která by neměla zůstat zcela nepovšimnuta.

Uvedu jen krátké citace, zájemci nechť si přečtou celý originál:

Pracovní skupina nebyla informována. Všichni ve skupině se o ukončení dozvěděli z tisku, nikoliv od W3C.

Dokument s často kladenými otázkami byl rovněž publikován bez konzulace s pracovní skupinou.

Předseda XHTML2 WG říká: XHTML2 není mrtvé a bude se vyvíjet mimo W3C

2009-07-09T18:30:00.003+02:00

O konci XHTML2 se objevila řada zpráv včetně oficiálních a potvrzených. Ty nejdůležitější jsem srhnoval nedávno v R.I.P. XHTML2 - pracovní skupina pro XHTML2 koncem roku ukončí svou činnost a v ...a ještě jednou o XHTML2 (aktualizováno). Zmínil jsem i možnost, že by někteří z tvůrců mohli v práci na XHTML2 pokračovat i nadále - mimo W3C.

Netušil jsem, že odpověď přijde tak rychle. Steven Pemberton, který předsedá pracovní skupině pro XHTML2, na svém blogu včera prohlásil:

Fakt, že W3C již nemá zdroje pro podporu XHTML2, neznamená, že XHTML2 již není potřeba, ani že společnosti, které na ní pracují, tuto práci chtějí ukončit. Řešíme proto, kde budeme v naší práci pokračovat, abychom ji mohli dokončit.

Mění se tím něco? Pro ty, kteří používají XHTML2 už dnes způsobem, jako ukázková stránka na w3future, se rozhodně jedná o radostnou zprávu. Přejme jim ji.

Ovšem pro řadové webdesignery se nic nemění. Rozkol mezi XHTML2 a stávajícím webem (zahrnujícím všechny stávající prohlížeče) je tak velký, že se téměř jedná o vzájemně výlučné elementy. Tam, kde jeden uspěje, není pro toho druhého místo. Před lety se věřilo na málo pravděpodobnou, ale přesto možnou budoucnost XHTML2. Dnes to vypadá na jasné vítězství klasického webu. Jak to bude vypadat za pár let, to se nechme překvapit.

Kvíz na závěr

BTW. S Adamem Haunerem se právě dohadujeme, zda Ian Hickson své tvrzení "Personally, I think XHTML2 is shaping up to be a great specification," v roce 2003 myslel vážně nebo se jednalo o ironii a nemůžeme se shodnout. Co si myslíte vy?

Noční buildy Firefoxu obsahují parser HTML5

2009-07-09T09:39:00.000+02:00

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í

...a ještě jednou o XHTML2 (aktualizováno)

2009-07-07T21:21:00.004+02:00

Není divu, že ukončení vývoje XHTML2 vyvolalo řadu dotazů. Ukázalo se také, že spousta webdesignerů a vývojářů nemá o vývoji u W3C ani ponětí (to jim nelze brát za zlé, to je jen důsledek chybějícího "informačního marketingu" W3C), a tak nabyla pocitu, že koncem XHTML2 končí celé XHTML, což není pravda. Vývoj XHTML pokračuje i nadále, jen nenavazuje na XHTML2, nýbrž na XHTML1.0.

Zpověď insidera

Objevilo se ovšem i několik zajímavých příspěvků. Pokud chodíte na pražská webdesignerská setkání PROWAS, jistě znáte jejich organizátora Jonny Axelssona, který se na XHTML2 dříve podílel (je uveden dle abecedního pořadí jako první z editorů specifikace XHTML2).

Jonny dnes na blogu rozebírá situaci v XHTML2. Je velmi zajímavé si to přečíst, protože Jonny ví, jak skupina skutečně fungovala a může nám tak napomoct pochopit historii. Mě zaujalo:

Nebylo to nikde oficiálně uvedeno, ale jednou z hlavních motivací vytváření XHTML2 bylo nabídnout přesvědčivý důvod pro přechod od HTML ke XHTML, tedy něco, co předchozí specifikace nemohly nabídnout.

A také:

Totéž platí pro odůvodnění pracovní skupiny nepublikovat errata k HTML4, protože budoucnost je v XHTML. HTML5 v podstatě obsahuje HTML4 errata.

Další dva zajímavé články, které stojí za přečtení, jsou poněkud polarizované:

Jeffrey Zeldman kritizuje aktuální dění
Henri Sivonen se snaží vysvětlit, proč je vše v pořádku a proč ze Jeffrey mýlí.

Přeberte si to sami. Téma XHTML je dnes víc horké než kdy dříve a zřejmě se na tohle téma dočteme ještě hodně zajímavostí a ještě mnohem více nesmyslů a nepřesností.

Aktualizace

Své k tématu před pár hodinami napsal i David Baron z Mozilly a nabízí zajímavý pohled, který ledacos vysvětluje. Dovolím si proto přidat jednu citaci:

Práce na XHTML2 začala v době, kdy technologie, na kterých stál Web stagnovaly (jak to zakusila řada uživatelů a poskytovatelů obsahu). Internet Explorer měl na trhu prohlížečů monopol resp. téměř monopol. Microsoft zpomaloval vývoj nových verzí Internet Exploreru v naději, že webové aplikace nebudou schopny konkurovat aplikacím na Windows a aplikace na Windows udrží uživatele vázané na operační systém Windows.

Proto bylo XHTML2 vyvíjeno bez očekávání, že by jej hlavní prohlížeč vůbec kdy implementoval. Jiné pracovní skupiny, které se věnovaly webovým technologiím, nadále spolupracovaly s ostatními výrobci prohlížečů v naději, že úspěch jejich technologie v těchto prohlížečích možná Microsoft přiměje je implementovat. Nicméně vývojáři XHTML zaujaly extrémější pozici: chtěli vytvořit samostatný Web na své vlastní technologii vytvořený "tím správným způsobem". Tento Web by byl prohlížen odlišným softwarem, který by eventuelně vytlačil stávající webové prohlížeče - všechny webové prohlížeče.

Přiznám se, že tenhle poznatek je pro mě nový, zájemcům rozhodně doporučuji přečíst celý Davidův článek ex-HTML, který se snaží vysvětlit, proč XHTML2 stálo bokem od VŠECH výrobců prohlížečů a proč se následně tak izolovalo od celého Webu, jak jej známe dnes.

R.I.P. XHTML2 - pracovní skupina pro XHTML2 koncem roku ukončí svou činnost

2009-07-02T21:21:00.001+02:00

Dnes Tim Berners-Lee oznámil, že XHTML2 WG koncem tohoto roku ukončí svou činnost. Přesněji bylo řečeno, že plán pracovní skupiny pro XHTML2 byl navržen do konce roku 2009 a již nebude dále prodloužen. W3C se hodlá soustředit na HTML WG a urychlit vývoj HTML5.

A co bude s XHTML2?

To má zvláštní osud. Myšlenka nového pěkného formátu postaveného na XML není jistě k zahození, ovšem ona implementace se zjevně nepovedla. Opakovaně můžeme slyšet kritiku, která se na vytvořený XHTML2 snáší. O XHTML2 se poměrně negativně vyjadřuje i Jiří Kosek jinak velký propagátor XML technologií (dokonce největší, jakého znám).

Poslední veřejná verze specifikace XHTML2 je pracovní návrh z roku 2006, je zhola nemožné, aby do konce roku prošel všemi specifikačními stádii až po final recommendation. Její osud pod křídly W3C je zpečetěn.

Je možné, že někteří z tvůrců XHTML2 budou v jeho tvorbě i nadále pokračovat, ovšem tento formát asi nebude ze strany W3C prosazován, o jeho osudu rozhodne trh. Pokud někdo tento formát bude potřebovat, může podpořit nebo sponzorovat jeho dokončení. Pokud se nikdo takový nenajde, tak nejspíš tento formát časem zmizí z povrchu země.

Co další specifikace?

Ovšem XHTML2 WG poslední roky nezahálela, když si proscanujete archiv novinek z roku 2009, 2008 a 2007 na slovo XHTML, najdete několik jejích dalších aktivit (včetně letošních inovací XHTML1 a XHTML1.1, které byly následně odvolány - můžeme přemýšlet, zda ono odvolání nebylo signálem, že něco není v pořádku).

W3C se bude muset rozhodnout, do jakých skupin tyto aktivity přesune, příp. zda pro některé z nich založí vlastní skupinu (např. o konkurenta mikroformátů RDFa je zájem, proto práce na něm bude jistě brzy pokračovat). Některé aktivity budou zaříznuty (kromě vlastního XHTML2 bude ukončena např. XFrames, HLink a další).

XHTML FAQ

K této příležitosti byla vytvořena speciální stránka FAQ o budoucnosti XHTML, kde se dozvíte, že ukončení XHTML2 WG je rozhodnutí managementu W3C, že na pracovní skupinu pro HTML bude nyní W3C věnovat více prostředků - myšleno hlavně personálních (už bylo na čase).

W3C také míní dohlídnout, aby vznikající XHTML5 (XML varianta HTML5) byla zcela kompatibilní s XML. Najdete v něm i podrobný přehled specifikací pracovní skupiny pro XHTML2, na kterých bude práce ukončena.

Osud XHTML2 byl de facto zpečetěn již na jaře roku 2007, kdy W3C oficiálně adoptovalo HTML5. Dnes bylo toto zpečetění jen řádně orazítkováno, podepsáno a založeno do archivu.

Jednání selhala. Společný kodek na Webu se nekoná

2009-07-02T09:10:00.004+02:00

Více než rok probíhaly diskuse s výrobci prohlížečů (částečně za zavřenými dveřmi) ve snaze nalézt dohodu a najít kodek pro video a zvuk, na kterém by se všichni dohodli.

Jak ovšem Ian Hickson včera oznámil, jednání selhala. Situace je následující:

Apple odmítá implementovat Ogg Theora do Quicktime (který je využíván prohlížečem Safari), zmiňuje špatnou hardwarovou podporu a nejistotu v oblasti patentů.

Google do Chrome implementoval H.264 a Ogg Theora, ale nemůže nabídnout licenci na kodek H.264 třetím stranám, které distribuují Chromium, a je také přesvědčen, že kvality Ogg Theora nejsou zatím vhodné pro nasazení na hojně navštěvovaný YouTube.

Opera odmítá implementovat H.264 citujíc nehoráznou cenu za potřebné licence.

Mozilla odmítá implementovat H.264, jelikož není schopna získat licenci, která by se vztahovala na její další distributory.

Microsoft se k podpoře značky <video> vůbec nevyjádřil.

Jak sami vidíte, jedná se o bludiště, ze kterého v tuhle chvíli nevede žádná cesta ven.

Co to znamená?

Nic nového. Web a média na webu zůstává taková, jaká je známe dnes. Aliance Open Video nebo konference o open videu budou i nadále pokračovat, je ovšem otázka, zda budou mít nějaký smysl.

Ian Hickson k tomu dodává:

Při pohledu do budoucnosti vidím dvě možnosti (vzájemně nevýlučné), obě by mohly nastat ale až za několik let:

1. Kodek Ogg Theora se bude nadále zlepšovat. Objeví se hadware obsahující chipy s podporou Ogg. Google jej bude distribuovat dostatečně dlouho, aniž by jej někdo žaloval a obava Applu ze skrytých patentů již nebude tak veliká. Následně se Theora stane de facto standardním kodekem na Webu.

2. Vyprší zbylé patenty H.264, které vlastní společnosti, jež je odmítají volně licencovat, tak bude možné distrubuovat H.264 bez licenčních poplatků a H.264 se stane de facto standardním kodekem Webu.

Já tady vidím ještě třetí možnost, byť si nejsem jist, nakolik je realizovatelná. Jak již historie webu ukázala, pro prosazení nějaké novinky není vlastně nutné, aby výrobci prohlížečů onu vlastnost implementovaly, stačí, když v nich lze alespon do jisté míry emulovat.

Pokud by se ukázalo, že taková emulace (v tomto případě pro kodek Theora OGG, protože emulovat H.264 by z licenčních důvodů asi opět nešlo) je dostatečně výkonná (ať už poběží v Javě, Silverlightu, Flashi nebo samotném JavaScriptu), pak není co dále řešit. Je otázka, jak dobře by takovou emulaci dnešní hardware zvládl. Během let se ovšem i tahle bariéra bude snižovat a proto tady jistou šanci vidím.

Video ano, otevřený formát ne

Boj o otevřené video nebo o jednotný formát videa na webu (říkejte si tomu jak chcete) skončil neúspěšně. On ovšem neúspěšně vypadal už na začátku. Výrobci prohlížečů totiž zaspali. Kdyby tenhle problém řešily před lety, těsně před velkým nástupem videa na webu, dalo se možná něco ovlivnit, dnes už jen slepě přihlížejí a příliš prostoru nemají.

Jejich chyba. Nekorunovaným králem videa je a nadále zůstává Flash a formáty, které podporuje v této verzi, nebo bude podporovat ve verzích následujících.

Máte nejasnosti s HTML5? Poradí vám HTML5 doktor

2009-06-29T15:02:00.001+02:00

Zajímavý blog pod názvem HTML5Doctor spustila skupinka lidí, kteří s HTML5 sice nemají nic společného, ovšem sledují problematiku. Blog je zajímavý svou koncepcí. Na stránce Ask the doctor můžete položit svou otázku týkající se HTML5 a některý z autorů vám následně odpoví formou blog postu. Schválně to vyzkoušejte.

Já v té chvíli zavzpomínal, jaké jsou hlavní zdroje informací týkajících se HTML5. Jedná se hlavně o Blog WHATWG. Jeho nevýhodou je, že je často trochu hardcore a lidé neznalí pozadí vývoje HTML5 ne vždy všechno dobře pochopí.

Poměrně dobrým zdrojem je Planet HTML5, která integruje řadu zdrojů zabývajících se HTML5. Jednotlivé zdroje se liší, co se týče zaměření a kvality, ovšem jedná se asi o nejcennější zdroj informací, který si můžete v angličtině přát a asi to první, co bych zájemcům doporučil.

Konkurent YouTube od ThePirateBay bude postaven na HTML5

2009-06-28T20:55:00.005+02:00

Řada z vás to nejspíš už ví, koncem tohoto měsíce odcházím ze Zdrojáku, který jsem loni na podzim založil, a proto se zajímavosti týkající se HTML5 vracejí opět na tento blog. Čili by se to tu po necelém roce mohlo dočkat zas nějakého oživení.

Dnes mě zaujal email, který upozorňuje, že The Pirate Bay (ano onen kontroverzní server, o kterém se nedávno tolik psalo) pracuje na konkurentovi YouTube, kterého hodlá postavit na nových značkách audio a video z HTML5 (jejich technickému popisu jsem se věnoval dříve, viz archiv pro audio a video).

Mě to zarazilo. Ačkoliv budoucnosti médií dle HTML5 poměrně věřím, jejich podpora v prohlížečích dnes ještě není natolik dostatečná aby na nich šlo postavit celý web, natož konkurenta YouTube (on i takový Google vyslal zprávu, že budoucnost vidí v HTML5 a připravil demo, jak by mohlo vypadat Youtube postavené na HTML5, ovšem klasické YouTube z pochopitelných důvodů stále používá Flash).

Článek Pirate Bay’s YouTube Competitor is “Coming Soon” mi situaci trochu objasnil. Onen "konkurent" YouTube s názvem The Video Bay je "teprve" v přípravě a The Pirate Bay jej neplánují jen tak hned spustit. Myšlenku vytvořit takový server oznámili již před dvěma lety a k jeho spuštění má dojít pravděpodobně až za několik let.

Dobře, YouTube se tedy zatím bát nemusí (a otázka, zda při srovnání s tou rychlostí vývoje někdy vůbec bude muset), já se vrátím k technickým aspektům.

V takovém případě totiž rozhodnutí "postavíme to na HTML5" už nevypadá tak zle. Za těch pár let podpora značek video a audio v prohlížečích nebude něco výjimečného (ostatně pozítří má vyjít Firefox 3.5, který je bude podporovat) a u serveru, který aktivně vyznává svobodné sdílení je použití svobodných technologií celkem nasnadě. Je to samozřejmě risk - nikdo 100% nezaručí, že v té době bude podpora značek bude konkurenceschopná (a hlavně podpora OGG kodeků, na které The Video Bay rovněž sází) - ovšem risk, který takový "alternativní" server, jakým The Pirate Bay beze sporu je, nemá problém podstoupit.

Pokud máte RC verzi Firefoxu 3.5, stabilní Chrome 3, experimentální verze Opery nebo Safari, můžete si na experimentální verzi portálu The Video Bay pustit ukázkové video nebo audio (fungují jen tyhle dvě ukázky, zbytek webu je zatím veřejnosti nepřístupný).

Představa, že by něco zatím tak nefunkčního mohlo konkurovat YouTube ne úsměvná, mě ovšem mnohem víc zajímá zralost jednotlivých částí HTML5. Když jsem před rokem zkoumal podporu audia a videa v Safari a Firefoxu, řada věcí fungovala špatně nebo vůbec a při experimentování jsem musel vycházet přímo ze specifikace. Dnes je to s podporou mnohem lepší a i veřejně se celkem často můžete setkávat s termínem "open video" (pořádají se na toto téma i konference). Ještě možná tak rok může trvat, než se tahle technologie rozšíří natolik, aby mělo smysl ji alespoň v některých specifických případech používat. Zatímco ještě nedávno jsem při svých přednáškách říkal, že značky video a audio zatím nelze v žádném použít, tuším, už za takový rok to nejspíš říkat nebudu. A to mě těší.

Do použitelné vyzrálosti, které se těší třeba takový canvas, mají ještě daleko, ovšem postoupili na další stupeň k vytčenému cíli.

U zpovědi

2009-05-07T08:45:00.000+02:00

Nedávno jsem poskytl rozhovor magazínu 30 minut. Najdete ho rozdělený na dva díly (možná by se celý magazín měl spíš přejmenovat na 60 minut nebo na 2x30 minut 8-):

Redakce Zdrojáku je můj notebook se týká mé současné práce na magazínu Zdrojak.cz.
Čím více je prohlížečů, tím lépe funguje jejich trh pak probírá stav na trhu prohlížečů a webových standardů.

Tak a já teď půjdu zas pro změnu přepsat a přeložit jeden webdesignerský rozhovor, který mám pro Zdroják připravený já.

Máte připomínku k webovým standardům? Založte si doménu

2009-04-08T11:45:00.001+02:00

Dnes nečekejte nic duchaplného, jedná se jen o malou vtipnou vložku. Pokud máte připomínku k nějakému standardu, ať již webovému u W3C nebo jakémukoliv jinému, zpravidla vždy najdete nějakou komunikační adresu nebo mailing list, na kterou můžete váš požadavek zaslat.

Pokud bude mít hlavu a patu, určitě se na něj někdo podívá. Ostatně takhle začínala i řada lidí, které si dnes se standardy spojujeme, i takový Jirka Kosek takhle začínal.

Existuje ovšem i další způsob, o kterém jsem dodnes nevěděl. Ptáte se jaký? Místo psaní dopisu si založte vlastní web (název domény musí být pochopitelně relevantní k vašemu požadavku), kde podrobně popíšete váš požadavek - pochopitelně nezapomenete na patřičné ilustrace a také vytvoření krátkého videa (webcastu), který váš požadavek detailně popíše.

Vedle webu si rozhodně založte i diskusní skupinu, ať můžete o problému diskutovat s ostatními. A nezapomeňte sbírat podpisy všech lidí, kteří s vámi souhlasí. Pak už můžete jen čekat, že si vás W3C všimne a že vašemu požadavku vyhoví...

Jak takový výsledek může vypadat? Inu třeba jako web www.addfullsize.com. (A už si ho skutečně někdo všimnul.)

Takže až vás někdy napadne připomínkovat nějakou specifikaci a budete chtít napsat dopis, zadržte ještě a zvažte, že existuje i alternativní způsob.

To není pochopitelně všechno, můžete si vytvořit skupinu na Facebooku, kde budete váš nápad propagovat, můžete si vytvořit kanál na Twitteru, kam budete hlásit, kolik již máte příznivců a kde se s nimi scházíte.

Prostě nebuďte staromódní - kdo by dnes psal jen nějaký obyčejný email, když máme takovéhle možnosti, že?

Znáte HTML značku KEYGEN? Brzy bude oficiální

2009-04-07T16:50:00.001+02:00

Předpokládám, že jen pamětníci znají značku <keygen>, kterou zavedl starý Netscape. Pokud vím, nikdy se nestala součástí žádné HTML specifikace. Tedy až dosud.

Používala se ve formulářích (přesněji řečeno jedná se o regulérní formulářový prvek) a měla co činit se šifrováním. Přesný mechanismus jejího použití jsem nestudoval, vím jen, že vygeneruje pár klíčů - veřejný klíč je odeslán spolu s formulářem, soukromý klíč zůstane uložen na straně prohlížeče. Pro zájemce tu mám základní informace, příp. dokumentace u Mozilly.

Myslel jsem si, že se jedná o historický relikt a dnešní prohlížeče ji už dávno nepodporují, ale mýlil jsem se. Jak jsem si vyzkoušel, je podporována ve Firefoxu, WebKitu i Opeře (vyzkoušejte na ukázce), tedy kromě IE prakticky všude (tudíž jedna z široce podporovaných značek, o které nikdo neví). To už je dost k tomu, aby si zasloužila standardizaci. A Ian Hickson ji také včera začlenil do HTML5, kde můžete najít její aktuální popis.

Uvádím to tu spíše jako kuriozitu, nepředpokládám, že když jste se dosud bez téhle značky obešli, tak ji budete chtít použít jen proto, že je standardizována. Ale možná, že nás nějaký bezpečnostní expert o její potřebě poučí.

Chcete ovlivnit HTML5? Ale prosím beze všeho

2009-04-03T09:16:00.003+02:00

Editor HTML5 Ian Hickson včera vyslal veřejnou výzvu k připomínkování HTML5. HTML5 sice není zdaleka hotovo, ale za ty roky už poměrně vyzrálo.

Ian Hickson popisuje, kam a jak máte nalezené problémy hlásit. Slibuje, že kdokoliv najde ve specifikaci problém (jakkoliv nepatrný včetně překlepů), bude zvěčněn v děkovacím seznamu na konci specifikace HTML5.

Pokud jste náhodou přemýšleli, že se někdy na specifikaci HTML5 chcete podívat, máte teď o důvod víc.

Čtyři vyčleněné sekce ze specifikace HTML5

2009-03-30T11:04:00.007+02:00

Z HTML5 byly vyčleněny 4 sekce, které přechází do samostatných specifikací, o které se bude nadále starat pracovní skupina WebApps. Oznámil to Ian Hickson v mailing listu HTML WG. Jedná se o následující sekce:

Vyčlenění proběhlo v rámci procesu zeštíhlení HTML5. Zatím jsem nikde nezahlédl jména nových editorů - tiše předpokládám, že nějací jsou, když k došlo k vyčlenění - zatím je všude podepsán stále Ian Hickson.

Nedá se vyloučit, že se nejedná o poslední vyčleněné sekce.

Ačkoliv se jedná o samostatné dokumenty, hovoří se v nich o závislosti na specifikaci HTML5, což na mě působí trochu schizofrenně. Nejsem si teď úplně jistý, zda je i nadále správně tvrdit, že např. localStorage je součásti HTML5 nebo ne. Odpověď nyní zní: Tak napůl. Ale možná to je jen dočasný stav.

Většina čtenářů tohoto blogu již asi ví, ale pro ty, kteří se diví, proč je zde poslední měsíce tak málo příspěvků připomínám, že většina obsahu se přesunula na Zdroják pod štítek HTML5.

(Ne)budou oba předsedové HTML WG z Microsoftu?

2009-03-11T09:01:00.012+01:00

V HTML WG celkem neplánovaně nastala nečekaná situace. Jejími stávajícími předsedy jsou Chris Wilson (Microsoft) a Sam Ruby (IBM).

Sam v blízké době očekává pracovní nabídku od Microsoftu. Tím by celé vedení HTML WG pocházelo z jedné společnosti. O co víc, zrovna z Microsoftu, který nemá v oblasti webových standardů to nejlepší jméno (můžeme diskutovat, nakolik je ta kritika oprávněná, nakolik ne, ale to je asi tak vše - Microsoft prostě má Černého Petra).

Druhý předseda, Chris Wilson, potvrdil, že ani on ani Sam z dlouhodobé perspektivy nevidí jako ideální řešení, aby oba předsedové byli z jedné společnosti a v případě, že by Sam do Microsoftu nastoupil, se pokusí situaci nějak vyřešit.

Pěkná hříčka osudu. Oba pánové jsou v oboru velmi uznávaní (Sam např. za své přispívání do Apache Foundation, Chrise zase najdete najdete v seznamu lidí, kteří přispěli k rozvoji webu měrou nejvyšší). V praxi ale rozhoduje i to, za jaký tým právě oba "kopou".

Pozn.: Naprosto stejná situace by nastala i v opačném případě, kdyby Chris hodlal přestoupit do IBM, jen by to možná nemělo tak silný emocionální podtext.

Michaelův dokument o HTML5: má být závazný či nikoliv?

2009-02-12T15:15:00.000+01:00

Zaměstnanec W3C, Michael Smith, nedávno publikoval dokument HTML 5: The Markup Language, který detailně popisuje značkovací jazyk HTML5.

Strhla se okolo něj poměrně velká debata. Má se jednat o oficiální specifikaci nebo jen o pomocný dokument? Celou situaci poměrně detailně rozebírá Arun Ranganathan.

Proč vznikly okolo takové zdánlivé maličkosti tak velké dohady se pouze domnívám. Pokud by byl tento dokument závazný, pak si mohla být celá specifikace HTML5 rozdělena na více dokumentů (a další dokumenty by mohl mít pod kontrolou někdo jiný než Ian Hickson). Některí to chtějí, jiní nikoliv.

Zástupci Mozilly a Safari se oficiálně vyjádřili, aby se nic neměnilo a tím jediným závazným dokumentem zůstala stávající specifikace HTML5.

Pokud si teď říkáte, že příprava standardů musí být občas pěkné hašteření, tak vězte, že rozhodně ano. Jak ostatně napovídá dnešní rozhovor Příprava specifikací je boj, který jsem pro Zdroják vedl s Jirkou Koskem (invited expertem pracovní skupiny pro HTML), a který se mimo jiné věnuje právě W3C a pracovní skupině pro HTML.

Adobe bude financovat bývalého předsedu HTML WG Dana Connolyho

2009-01-24T22:04:00.008+01:00

Bývalý předseda HTML WG Dan Connolly, který od února bude u W3C placen jen na polovinu úvazku, včera oznámil, že onu druhou polovinu mu bude platit - hádejte kdo? - společnost Adobe.

Dan Connolly se podle smlouvy s Adobe má stát dalším editorem HTML WG (dříve byl jejím předsedou, ale již před časem tuto funkci předal Samu Ruby z IBM) a plánuje se zaměřit zejména na psaní návodů a tutoriálů souvisejících s HTML5. (Ty budou potřeba jak sůl, protože samotná specifikace HTML5 není vždy pro webdesignery snadno čitelná.)

Přiznám se, že mě tento krok společnosti Adobe trochu zaskočil, přeci jen se svými obchodními zájmy týkající se Flashe a všech Flexů a AIRů stojí spíše na druhé straně barikády. Možná mi něco uniklo, ale nedokážu si tenhle krok zatím vysvětlit. Proč by nějaká společnost financovala rozvoj technologie, která je pro ni v tuto chvíli sice nezbytná, ale pro další vývoj jasně konkurenční?

Před dvěma lety jsem si tady stěžoval, že nechápu, proč Adobe už dávno nemá svého zástupce v HTML WG, ale ve snu by mě nenapadlo, že si v ní jednoho dne zajistí přímo místo editora.

Každopádně HTML WG (a ostatně celé W3C) potřebuje člověkohodiny jako sůl. W3C peníze nazbyt nemá, tak to od Adobe zatím vypadá jako šlechetné gesto.

Teď už nám zbývá, aby se do HTML WG zapojil i Sun a partička bude kompletní 8-)

K celé věci se zajímavě vyjádřil i Ian Hickson. Prý by ho nikdy nenapadlo, že se jeho jméno někdy objeví na pracovní smlouvě, která není uzavřena s ním (smlouva s Danem Connollym přímo obsahuje, že má pomoci Ianu Hicksonovi ulehčit jeho editorskou zátěž).

WebForms2 zmigrovány do HTML5

2009-01-05T21:21:00.004+01:00

Dnes byla dokončena migrace specifikace WebForms 2 do HTML5. Na začátku specifikace Web Forms2 nyní najdete varování:

This draft has been superseded by the Forms chapter of the HTML5 specification, which now includes many of the features first defined in this document.

This document will not be further updated.

Zmigrována byla většina specifikace, až na některé části, jejich odstranění bylo již dříve avizováno (např. repetition model). Časem si zmigrovanou specifikaci pročtu detailně a pokud bude čas, zkusím pro zájemce sepsat detail změn.

HTML5 mezi webovými technologiemi roku 2008

2009-01-01T16:15:00.002+01:00

Magazín Wired sestavil seznam nových webových technologiích, které byste si neměli nechat ujít. Najdete mezi nimi i HTML5.

Není to zas tak překvapivé. Pokud sledujete tento blog pravidelně, jistě víte, že HTML5 není jen hudbou budoucnosti, ale některé jeho části můžete používat již dnes nebo v blízké době. Jejich přehled byl součástí mé podzimní přednášky HTML5 is happening.

HTML5 se pomalu ale jistě dostává do všeobecného povědomí vývojářů a podpory oficiálních nástrojů (např. nedávno zařazená podpora HTML5 do validátoru W3C).

V roce 2009 bude tento trend ještě sílit. A pravděpodobně se vyjasní některé dosud nerozřešené klíčové otázky, hlavně tyto dvě:

jaká bude budoucnost Web Forms 2 (Stanou součástí HTML5? V jaké podobě?)
zda specifikace HTML5 bude existovat v podobě, jakou známe dnes, nebo se některé její části oddělí do menších specifikací

Kde a jak Ian Hickson sbírá feedback k HTML5?

2008-12-07T16:09:00.006+01:00

Na Standards Suck vyšel krátký rozhovor s Ianem Hicksonem. Poslechněte si v něm mj. jak a kde všude Ian sbírá feedback při své práci editora HTML5 (myslím, že je to docela zajímavé).

Hixie on Editing HTML5 from Standards Suck on Vimeo.

Parser HTML5 experimentálně i v Mozille

2008-12-05T00:14:00.004+01:00

O několika HTML5 parserech jsem se již zmiňoval (viz příspěvky se štítkem parser). Henri Sivonen vytvořil experimentální build Mozilly používající právě HTML5 parser. Jedná se o zajímavou ukázku. V době, kdy žádný prohlížeče neobsahuje HTML5 kompatibilní parser (na to je ještě brzy) tu máme alespoň experimentální verzi.

Sam Ruby tento zajímavý počin komentuje:

Henri’s approach is interesting. He starts from a single source, in Java. The Java code can be compiled to Java byte codes, JavaScript source, or C++ presumably making use of Mozilla libraries for things such as memory management. If he can do that, it seems to me to be a rather small leap from there to producing C++ using, say, either Ruby or Python libraries for memory management, as well as a thin binding to the language. C# would also be a reasonable target.

If this could be done, and made available under a liberal license, it could go a long way towards making available consistent and performant implementations of the HTML5 parser algorithm everywhere.

Slidy z přednášky Představení HTML5

2008-11-30T10:25:00.005+01:00

Před týdnem jsem měl na semináři Junior Internet přednášku Představení HTML5.

Pro zájemce vystavuji slidy.

Předváděl jsem i několik online ukázek, jejich přehled najdete v mých Del.icio.us záložkách.

Formulářové prvky dostanou placeholder

2008-11-17T18:35:00.012+01:00

Všimli jste si, že řada webů dnes používá v hledacích polích malou nápovědu? Jedná se o text, který se zobrazuje, když je textové pole prázdné. Jakmile do pole umístíte kurzor, abyste začali psát, nápověda zmizí. Typicky se jedná o text "Zadejte hledaný výraz", "Váš e-mail", "www.example.cz", který jednak uživateli s psaním pomůže a také upoutá pohled uživatele k formuláři.

V poněkud sofistikovanějším provedení takové řešení můžete vidět vpravo nahoře na www.weblogy.cz (tam je kromě textu zobrazeno i logo Googlu). Prázdné textové pole je nevyužitá plocha, proč ji nevyužít (v případě Googlu dokonce k propagaci značky).

K realizaci takové nápovědy je ovšem nutný JavaScript. Podle moudrého pravidla úkoly, které se dělají často, by se měly dát dělat jednoduše textovým formulářovým prvkům nově přibude atribut placeholder, který výše uvedenou funkcionalitu zastane. Použití je snadné:

<input type="email" placeholder="jan@example.cz">

Atribut placeholder dostane nejen input s type="text", ale i nově zavedené značky z WebForms2, např. type="email", type="url" apod.

Specifikace říká, že placeholder má obsahovat krátkou nápovědu sloužící uživateli k vyplnění pole. K delší nápovědě může být použit např. atribut title. Prohlížeče text atributu placeholder zobrazí pouze v případě, kdy je formulářové pole prázdné a nemá focus.

Více najdete v příslušném diffu specifikace (musíte odscrollovat až téměř nakonec).

Přehledný dokument jazyka HTML5

2008-11-14T08:00:00.001+01:00

Jelikož specifikace HTML5 je relativně dlouhá a primárně určená pro implementátory nikoliv webdesignery, pokouší se Michael Smith z ní připravit jednoduchý výtah, který by byl pro designery a kde by šlo přehledně nalézt pouze informace o jazyce HTML (bez informaci o DOM apod.).

Pracovní návrh je tohoto dokumentu vám k dispozici.

Libo být editorem budoucnosti HTML?

2008-11-04T00:00:00.010+01:00

Specifikace HTML5 není zrovna malá. Když se jejího editora Iana Hicksona někdo zeptá, proč některé části nevyčlení do zvláštních specifikací (protože by z logických důvodů lépe fungovaly zvlášť, jmenujme například canvas) odpoví, že by mohl, ale není po ruce editor, který by si vzal vyčleněnou specifikaci na starosti. Ve výsledku by to proto znamenalo nikoliv onu část vyčlenit, ale zahodit. Proto některé části setrvávají (a nejspíš i navěky setrvají) uvnitř HTML5.

Nedávno si dal Ian práci a zmíněné části zveřejnil včetně odhadu, kolik by zabraly editorovi času. (Velmi doporučuji, abyste se na ten čas podívali, ať máte představu, jak dlouho může vytvoření pořádné specifikace trvat a vzpomeňte si na to, až si budete někdy stěžovat, že specifikace XY není tak dokonalá, jak byste si přáli!)

Zároveň Ian přidal nápady, které se do HTML5 už nedostanou, ale které by stáli za realizaci (např. 3D mód canvasu).

Vypisuji jednotlivá témata, pro podrobnější popis se podívejte do původního mailu:

HTML5 Rendering and UA behavior
Interaction events
3D Canvas
UndoManager
Stylesheet DOM
URL
Common DOM interfaces
Content-Type handling and content sniffing
2D Canvas
Platform Core

Co myslíte, najde se editor aspoň na jedno z nich? A kdo je zaplatí? Jsem sám zvědav.

Dvě přednášky o HTML5 už brzy

2008-10-29T23:00:00.008+01:00

Pokud jste náhodou z Brna, tak tuhle sobotu 1.11. mám na konferenci LinuxAlt (vstup zdarma) přednášku Média v HTML5 věnovanou zejména novým značkám video, audio a canvas (viz program konference).

Pokud jste náhodou z Prahy, tak hned další čtvrtek 6.11. mám v rámci akcí PROWAS (taktéž zdarma) v Praze přednášku HTML5 is happening věnovanou zejména těm částem HTML5, které již byly implementovány (viz pozvánka).

Rád tam uvidím nejen čtenáře tohoto blogu.

A pokud to máte daleko jak do Prahy, tak do Brna, tak se omlouvám 8-)

Aktualizace: Slidy z přednášky Média v HTML5.

Zdroják a proč sem teď tak často nepíšu

2008-10-28T10:50:00.011+01:00

Pokud se divíte, proč na HTML456 poslední dobou tak často nepíšu, je to proto, že jsem nedávno pod křídly Internet Infa spustil nový magazín Zdroják, který je určený pro webdesignery a webové vývojáře.

HTML456 míním psát i nadále, ale řadu informací teď najdete přímo na Zdrojáku, který vám doporučuji začít sledovat, protože ne vždy budu texty o HTML5, které vyjdou na Zdrojáku, linkovat i z tohoto blogu.

Jsou snadno k nalezení, protože jsou všechny označeny nálepkou HTML5 (už teď jich na Zdrojáku najdete skoro deset!). A ke sledování můžete použít i RSS zpráviček a RSS článků.

Předvolba pro vypnutí autoplay videa

2008-10-15T09:55:00.001+02:00

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.

Ian Hickson: vlastnosti, které zoufale chcete, ale ještě nemůžete použít

2008-09-28T12:07:00.007+02:00

Editor HTML5 specifikace, Ian Hickson měl minulé pondělí přednášku o HTML5, na které předváděl již hotové nebo probíhající implementace klíčových částí HTML5. Záznam celé přednášky nalezenete na Youtube.

Přednáška trvá hodinu a podává pěkný přehled o celé šířce záběru HTML5. Pokud vás zajímají jen některé části, tady je osnova přednášky:

Úvod
<video> (00:35)
postMessage() (05:40)
localStorage (15:20)
sessionStorage (21:00)
API pro Drag and Drop (29:05)
onhashchange (37:30)
Formulářové prvky (40:50)
<canvas> (56:55)
Validace (1:07:20)
Dotazy (1:09:35)

Přednáška je velmi pěkná, pro její shlédnutí doporučuji jít přímo na Youtube, přepnout si na vyšší kvalitu a sledovat v celoobrazovkovém zobrazení. Uvidíte pak všechen předváděný kód.

Online najdete i všechny příklady z přednášky a komentáře k nim.

(Zdroj: Whatwg.org)

Proměnné v CSS - lesk a bída standardizace

2008-09-25T10:45:00.003+02:00

Řada webdesignerů se těší na brzké zavedení proměnných do CSS. Návrh specifikace vznikl velice rychle, WebKit je již implementoval a ačkoliv někteří s jejich zavedením nesouhlasí, vše se zdálo být na rychlé a bezproblémové cestě (což je ve světě webových standardů dosti neobvyklé!).

K jejich rychlému zavedení je třeba, aby byla včas specifikace prohlášena za stabilní, a aby prohlížeče CSS promněnné implementovaly. Obojí spolu souvisí. Čím dříve bude specifikace hotová, tím dříve se může objevit v prohlížečích a naopak čím dříve se objeví v některých prohlížečích, tím dříve může být hotova. (Že by kruh? Ale tak to prostě je.)

Ovšem od úterý probíhá v diskusní skupině CSS WG debata, ze které vyplývá, že nic není tak růžové. Dave Hyatt píše, že implementaci z WebKitu odstranil, protože ačkoliv všichni proměnné v CSS chtějí, nedaří se dohodnout, jak má jejich implementace vypadat:

It's off pending a decision of any kind. :) The feature works well, but it seems everyone has his/her own idea of how this feature should work, and nobody has the same opinion. I'm basically disgusted at this point and giving up on the whole feature.

A dodává, že nechce, aby se do ostré verze Safari (nebo Google Chrome) dostaly CSS proměnné v podobě, která není dosud jistá, protože tak dlouho očekávaná novinka by se začala rychle používat a WebKit by ji pak musel podporovat navěky, i přestože by oficiální implementace vypada úplně jinak:

The problem with leaving CSS variables turned on in WebKit is that if the feature ships, it is going to be hugely popular. We know this. Whatever we ship, we will have to support on OS X forever, because apps on the platform will scramble to use this feature.

Já sice chápu Davevovu opatrnost, ale myslím si, že přesně takovéhle nejisté oblasti jsou doménou vendor prefixů. Je to vlastně jeden z důvodů, proč se vendor prefixy používají a Dave toho (dle mě zbytečně) odmítá použít.

Na druhou stranu i ostatní prohlížeče obsahují vlastnosti, které sice jsou naprogramované, ale z nějakých důvodů se do veřejných verzí nedostávají (ať již nejsou dost otestované nebo by mohly být kontroverzní, případně se čeká na specifikaci), takže Davův postup není nijak výjimečný.

Pro designery to znamená jediné: CSS proměnných se sice dočkáme, ale možná přijdou ještě o něco později.

Pro zájemce celé vlákno [Css Variables] Variable Declaration Blocks.

Lesk a bída standardizace

Standardizace je pomalý proces. Sejde se vám kupa odborníků, každý má na věc jiný názor, no a teď standardizujte. Hlavně ale nepočítejte s tím, že se během pár měsíců na něčem dohodnete! Dejte si raději rezervu jednoho roku. Minimálně! Jen několik měsíců může trvat výběr správného názvu jednotlivých funkcí!

V HTML5 funguje (ano, skutečně to funguje!) metoda osvíceného diktátora. Všichni se pár týdnů o podobě nové vlastnosti hádají, pak si Ian Hickson sedne, sepíše návrh specifikace a zveřejní ji (tedy de facto rozhodne sám a za sebe, byť na základě návrhů ostatních). Následně se všichni hádají o jeho návrhu a objeví se pár blogpostů, že Hickson celou skupinou manipuluje a nikdo kromě něj nemá na specifikaci vliv, nebo někdo ze skupiny protestně odejde.

Hickson ty nadávky igronuje a podívá se na kritiku návrhu, vybere z ní nejlepší myšlenky a svůj návrh podle nich přepíše. Tohle kolečko se ještě dvakrát zopakuje a ve výsledku tu je specifikace, se kterou naprostá většina zúčastněných souhlasí a je s ní spokojená.

Existuje i další "standardizační" proces, kdy se výrobci jednoho prohlížeče pro něco rozhodnou, rychle to naimplementují a vydají. Druhý prohlížeč to naimplementuje taky (někdy trochu jinak, protože ten první prohlížeč k tomu nedal pořádnou specifikaci) a než se nadějeme, používáme to všichni. Je to sice plné problémů, je to návrh, za který se někde i vyhazuje od zkoušky, ale světe div se, vývojáři jsou rádi, že aspoň něco mají.

Tak a teď si vyberte!

Máme tu několik špatných cest. Jenže tu dobrou cestu nikdo nezná, a tak se vývoj webu často odehrávách na těch cestách, které jsou zrovna v tu chvíli z těch všech špatných ty nejméně špatné.

Vzpomeňte si na to, až zas někde uslyšíte, že Ian Hickson je diktátor, nebo že prohlížeč XY implementoval cosi svého. Netvrdím, že je to správné, ale někdy to může být to nejlepší řešení.

Budou HTML formulář přímo přistupovat ke kameře?

2008-09-24T10:20:00.001+02:00

Brad Lassey ve svých úvahách o mobilní verzi Firefoxu dospěl k zajímavému nápadu:

<input type=”camera” />

Posílání videí (nebo i fotek) pořízených z kamer připojených k počítači roste. (A to už vůbec nemluvím o mobilních telefonech!) Proč celý proces neusnadnit a neintegrovat do webového prohlížeče? Potřebujete nahrát do svého profilu na Facebooku fotografii? Stačí kliknout na input, vyfotit se a prohlížeč výsledek odešle. Když prohlížeče dokážou přehrávat <video>, proč by jej neměli umět také vytvářet?

Daniel Glazman zdůrazňuje několik bezpečnostních aspektů, ale s nápadem souhlasí a navrhuje začlenit ho do HTML5.

V HTML5 konferenci (resp. ani v jedné z těch dvou konferencí) se návrh zatím neobjevil. Jsem zvědav. Já bych pro něj hlasoval všemi deseti. Bylo by nutné zajistit, aby mohl být ve starších prohlížečích emulován klasickým <input type="file">, ale to je tak všechno.

BTW Jistě není náhodou, že se tento nápad objevil krátce po virální akci blogerů Mozilly.

Když si Firefox zapingá

2008-09-21T18:00:00.003+02:00

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í!

Ukázka podpory videa ve Firefoxu 3.1

2008-09-18T17:15:00.002+02:00

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

WebForms2 migrují do HTML5

2008-09-16T08:30:00.009+02:00

Ian Hickson nedávno zahájil migraci specifikace WebForms2 do HTML5.

WebForms2 je samostatnou specifikací (z historických důvodů) a ačkoliv Ian dříve přislíbil její začlenění do HTML5, dosud neproběhlo. Pravděpodobně, protože John Boyer, předseda Forms WG, k ní měl loni vážné námitky. Za tím účelem byla vytvořena Forms Task Force, která měla problémý vyřešit. Nevšiml jsem si žádného veřejného výstupu, jejich mailová skupina za celý rok poměrně zeje prázdnotou.

Jsem zvědav, jak bude specifikace po začlenění vypadat, Ian v ní nyní provádí drobné úpravy a v nedávném rozhovoru naznačil, že dojde k vypuštění některých částí. Předpokládám, že tak za měsíc budeme moudřejší.

WebForms2 se poslední rok nacházela v patové situaci. Tím, že k ním měl předseda Boyer vážné připomínky, se z ní stal černý Petr, kterého nikdo nechtěl implementovat. No, implementovali byste něco, co se možná zítra změní a vy nevíte, zda kompletně nebo jen trochu?

Začleněním do HTML5 se situace vyjasní a prohlížeče budou mít volnou cestu k implementaci WebForms2. V tuto chvíli jsou WebForms2 implementované pouze v Opeře.

Debata o atributu alt se snad chýlí ke konci. A říká...

2008-09-12T00:10:00.003+02:00

Máme tu pokračování seriálu, jehož hlavním hrdinou je atribut alt a zápletka se náramně podobá filosofické otázce "Být či nebýt". (Můžete si připomenout předchozí díly.)

Ian Hickson pečlivě prošel všechny diskutované připomínky a nabízená řešení. Slovo "pečlivě" jsem zdůraznil, protože prostudování Ianova e-mailu vám chvíli potrvá. Obsahuje detailní rozbor problematiky a více jak 20 (!) možných řešení (ne)povinné existence altu. Nevěříte, že jich tolik existuje? Jen si to celé přečtěte, pokud máte čas. Ian ovšem také analyzuje jejich nedostatky a postupně je jedno po druhém zavrhuje.

Až na jedno!

Ian se pokusil najít kompromis a podařilo se mu získat větší příznivou odezvu než kdykoliv před tím. Než onen kompromis přednesu, zkusím vysvětlit, proč byl problém nepovinného altu vůbec otevřen. Jsou tu dva důvody, Web ani HTML už nejsou totéž co kdysi.

Důvod první

Web dnes není stejný jako v devadesátých letech, kdy se obrázky a alt zaváděly. Uživatelé na web nahrávají své fotky, přibývá počet fotogalerií. Kdo ví, možná se už dokonce fotka z víkendu nebo dovolené stala převažujícím typem obrázku na celém webu (podklady pro to nemám, ale pokud to nenastalo dnes, je asi jen otázkou času, kdy to přijde). Většina těchto fotek nemá atribut alt vyplněn a pokud ho vyplněn má, tak genericky (alt="Photo 45678").

Autor webu (fotogalerie) s tím nemůže nic dělat. Vlastními silami není schopen popisky desetitisícům fotografií doplnit. Museli by je doplňovat uživatelé. Ovšem, který z nich by chtěl po krásně prožité dovolené dopisovat popisky k desítkám nebo stovkám fotografií? Kdo ho může nutit?

To znamená, že možná již nejrozšířenější použití značky img se úvahám původních HTML specifikací trochu vymyká. Jasně, může se všude použít alt="", ovšem co když jednou budou fotogalerie čítat 90% obrázků na webu (a k tomu může dojít)? Bude i pak povinný alt správné a optimální řešení?

Přemýšlím dokonce, zda nevidomý člověk nutně potřebuje alternativní informaci u fotogalerií. Teď se vrhám na tenký led, ovšem myslím, že některé bariéry prostě překonat nedokážeme. Má pro nevidomého člověka smysl, aby při procházení fotogalerie četl: "já na mostě", "já nasedám do autobusu", "já jsem si koupila nový klobouk", "já...".

Jiný případ je, pokud vezmeme fotografii a použijeme ji jako doplnění nějakého textu. Tam jistě alternativní popis fotografie smysl má, obzvlášť, pokud text doplňuje nejen esteticky, ale i informačně, např. v textu píšu o veselé náladě na oslavě narozenin a na fotografii je vidět, že během zábavy si někteří pánové nasadili klaunské nosy, namalovali klaunskou pusu a vesele spolu tančí. Nenapsat to do popisku obrázku, pak nevidomý člověk přijde o část celého sdělení. A to byla škoda. Ovšem pokud vystavím fotogalerii všech 100 fotek z narozenin, zřejmě k nim nebudu přidávat takto podrobné popisky a asi by to ani nemělo velký smysl. Mnohem lepší bude, když o průběhu narozenin prostě něco pěkného napíšu. (Teď mě napadlo, že nejlepším alternativním obsahem fotogalerie asi nejsou popisky, ale článek. Nicméně neodbíhejme.)

Tento první důvod by sám o sobě ke zrušení povinného altu nestačil, ale je to dobrý důvod k zamyšlení. Pokud hrozí, že dnes nebo za pár let nebude mít smysl u většinového použití značky img vyplňovat alt, máme na altu stále trvat?

Hlavní protiargument zrušení povinného altu je, zda by to neohrozilo jeho používání tam, kde je nutný. Aneb alt se webdesigneři často naučí používat, protože jim vynadá validátor. Když jim nadávat přestane, kdo je to naučí?

Důvod druhý

Důvod druhý souvisí nikoliv s evolucí Webu, ale s evolucí HTML. HTML5 obsahuje nové konstrukce, které umožňují poskytnout alternativní obsah obrázku jinak, pro některé případy vhodnějším způsobem. Příkladem je značka figure, která propojí text s obrázkem:

<figure>
<img src="DSC_0399.JPG">
<legend>Tanečník u tyče s tričkem <a href="http://www.google.cz/">Googlu</a> vábí nové klienty</legend>
</figure>

Na rozdíl od altu, který je ALTERNATIVNÍM obsahem obrázku, je obsah značky legend jak alternativním obsahem obrázku, tak popisem obrázku pro všechny čtenáře. U obrázku v takové formaci nedává atribut alt smysl. Mělo by vůbec cenu značku figure zavádět, když by bylo nutné stejně alt (byť prázdný) vkládat? Neříkal by prázdný alt čtečkám, že alternativní informace neexistuje, místo aby je navedl na obsah značky legend?

Takže ten kompromis

Jak Web, tak HTML se nám vyvíjí a u atributu alt je třeba hledat řešení, které bude tento vývoj respektovat, ale zároveň neohrozí přístupnost Webu. A Ian po měsících debatování v HTML WG přišel s tímto kompromisním řešením:

Atribut alt může být vynechán pouze a jen v případě, že je alternativní obsah obrázku nabídnut jiným způsobem (např. značkami figure+legend nebo atributem title). V ostatních případech je alt povinný.

Možná vám tohle řešení připadne komplikované, ale jednodušší se už zřejmě nedá nalézt. A já mám takový pocit, že tohle řešení by už do finální specifikace mohlo projít. I když, raději si ještě počkáme.

Jo a řvaní validátoru nad absencí alternativního popisku se nezbavíme, protože jak alt, tak i ty alternativní způsoby si dokáže pěkně pohlídat.

Další čtení:

Canvas a pěkné obtékání obrázku

2008-09-09T11:10:00.008+02:00

Obtékání obrázků (a čehokoliv jiného) je v kaskádových stylech řešeno na úrovni bloků. Na papírovém médiu se ale můžeme setkat i s jemnějším obtékáním, které respektuje nepravidelný tvar obrázku.

Jacob Seidelin se pokusil jemný druh obtékání nasimulovat pomocí běžného HTML+CSS s pomocí JavaScriptu a canvasu. Stačí, abyste do stránky vložili obrázek s průhledným pozadím, nastavili mu správnou třídu (v našem případě "sandbag-left") a jednoduchý skript PrettyFloat se o zbytek postará.

Výsledek je celkem přesvědčivý (zatím jen ve Firefoxu a Opeře).

Jak to funguje? Canvas umožňuje přistupovat k obrázkům na úrovni jednotlivých pixelů. Skript zanalyzuje obrázek a nahradí jej sadou divů o výšce cca jednoho řádku textu, každému z nich nastaví adekvátní šířku a na pozadí napozicuje původní obrázek tak, aby jednotlivé divy daly vizuálně dohromady obrázek původní. Vše proběhne při onloadu a rozumně rychle. Mechanismus je postaven na metodě, která byla prvně popsána na Alistapart.

Vše se řídí pravidlem graceful degradation (v ostatních prohlížečích uvidíte klasické obtékání).

Nejedná se o jediný způsob zpracování obrázku pomocí canvasu, našli bychom knihovny na zaoblování rohů, vytváření zrcadlových obrazů atd. Přemýšlím, zda se podobné metody jednou ujmou stejně jako je dnes běžný SIFR.

Pozn.: Nejedná se o univerzální způsob, prohlížeč totiž povolí v canvasu zpracovávat jen obrázky ze stejné domény. Porušit toho omezení je nežádoucí (na pozadí by prohlížeč mohl např. lámat cizí captchy a uživatel by o tom neměl ponětí).

(Zdroj: nihilogic.dk)

Firefox implementuje drag & drop z HTML5

2008-09-03T13:10:00.003+02:00

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)

Přehled HTML5 značek na W3schools

2008-08-31T07:25:00.001+02:00

Na serveru w3schools.com se objevil stručný přehled značek HTML5. Pokud v HTML5 píšete, může se vám hodit, je rozhodně přehlednější než dolovat některé věci ze specifikace.

Pamatujte ale při tom, že W3schools nemá nic společného s W3C (kromě dvou znaků v názvu) a může se stát, že údaje na něm budou zastaralé nebo nepřesné (což zatím místy skutečně jsou).

Pokud se podíváte na pravé dva sloupce tabulky s přehledem značek, získáte představu, kolik značek je v HTML5 nových, a kolik jich naopak bylo vypuštěno. Pokud chcete srovnávat i s dalšími verzemi, použijte přehled značek Jense Meierta.

Firefox dokáže překreslit obsah videa do canvasu

2008-08-30T12:30:00.000+02:00

Do dalších verzí Firefoxu se dostane malé rozšíření canvasu. Konkrétně metody drawImage. Ta jako argument dostane existující obrázek, který vykreslí do canvasu. Dobře poslouží, pokud do canvasu chceme vykreslit komplikovaný obrázek, a protože nechceme začíst na zelené louce, hodláme vyjít z již existujícího obrázku.

Vývojáři Firefoxu metodu rozšíříli, takže dokáže pracovat nejen s obrázkem, ale i s videem vykreslovaným značkou video. Při zavolání drawImage v takovém případě dojde k vykreslení aktuálního zobrazeného snímku videa do canvasu.

Ian Hickson se dosud nevyjářil, zda toto rozšíření bude zahrnuto do specifikace či nikoliv.

(Via whatwg.org)

Rozhovor s Ianem Hicksonem na Techrepublic

2008-08-29T10:15:00.000+02:00

Na Techrepublic vyšel rozhovor s Ianem Hicksonem. Ian se rozepisuje o termínu dokončení HTML5 a vysvětluje "proč to celé trvá tak dlouho", popisuje, které části HTML5 vyvolaly rozporuplné reakce (např. probíhající kauza atributu alt), a jaké jsou největší úspěchy.

Několik citací:

We’re also fully intending to do something that none of the aforementioned specs really did, which is to have a comprehensive test suite that we will require at least two browsers to completely pass before we call it a day.

If one were to try to write such a test suite for HTML4 and DOM2 HTML, one would find that there isn’t even one browser that fully implements those specifications, let alone two.

The problem is that if we ever specify something that the browser vendors disagree with, they will just ignore the specification, and we might as well go home. If we write a specification that is ignored, we’re just fiction writers.

The features that don’t end up being used will be cut. We’ve already dropped a lot of things over the years, and I’m sure we’ll drop more.

Celý rozhovor HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more si můžete přečíst na Techrepublic.com.com (netušíte někdo, proč má v adrese 2x dotcom?)

Firefox asi implementuje window.toStaticHTML z IE8

2008-08-28T09:45:00.002+02:00

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.

Na Web přijde JavaScript s více vlákny

2008-08-27T14:55:00.004+02:00

Jednovláknovost JavaScriptu ve webových prohlížečích skýtá jistá omezení. Přitom v jednom vlákně neběží pouze skript jedné stránky, ale pokud se stránka skládá z více rámů nebo otevřela vyskakovací okno, pak všechny jejich skripty poběží v jednom jediném vláknu. Přitom se mezi sebou střídají pro obsluhování jednotlivých událostí. Celé to silně připomíná starý kooperativní multitasking. HTML5 se snaží dát zpracování události jistý řád a navíc umožní použití více vláken.

Event loops

Princip a pořadí obsluhování událostí je v HTML5 specifikován pomocí Event loops. Event loops zavádí fronty úloh, do kterých se ukládají např. události uživatelského rozhraní, události parseru nebo síťového rozhraní. Specifikace popisuje, v jakém pořadí mají být dále zpracovávány.

Ačkoliv jsou webové prohlížeče s námi již řadu let, jedná se, pokud vím, o historicky první specifikaci tohoto druhu. Dosud se prohlížeče mohly chovat každý jinak, což také i víceméně dělaly (přečtěte si loňskou diskusi u Misantropa). Ve výsledku tak zmizí další rozdíl způsobující, že webová aplikace v jednom prohlížeči běžela v pořádku a ve druhém způsobila nepochopitelný problém.

Přichází vlákna

Mnohem zajímavější je ovšem zavedení vláken do skriptování webových prohlížečů. Je jim věnována zvláštní specifikace Web Workers (zkráceně WW), čítá asi 30 stran a v budoucnu se pravděpodobně stane součástí velké specifikace HTML5.

Web Workers navíc ke stávajícímu vykonávání JavaScriptu definují pracovní vlákna, která běží na pozadí (mimo interakci s uživatelským rozhraním prohlížeče) a mají sloužit ke zpracování výkonnostně nebo časově náročnějších činností. Jelikož neblokují uživatelské rozhraní, nebudou omezovány, mohou tedy bez přestání běžet desítky minut nebo i hodin (průběh stávajících skriptů totiž bývá omezen např. na desítky vteřin ve Firefoxu, což komplikuje vykonávání náročnějších úloh).

Ukažme si jednochuché použití pracovního vlákna. Všimněte si, že pracovní vlákno s vláknem uživatelského rozhraní komunikuje prostřednictvím zpráv (událost message) - online verze:

<script>
var worker = new Worker('worker.js');
worker.onmessage = function(event){      document.getElementById('result').innerHTML = event.message;
};
</script>

Pracovní vlákno může získávat data pro svou práci pomocí událostí, database storage nebo pomocí síťové komunikace (komunikace s webovými servery pomocí AJAXu nebo nového rozhraní Web Sockets - o tom jindy). Přímý přístup k uživatelskému rozhraní nebo k zobrazované webové stránce pracovní vlákno NEMÁ.

Pracovní vlákno má navíc některé metody, např. importScripts(url1, url2...), která zajístí načtení dalších skriptů (potřebná metoda, nemůžeme totiž použít běžnou značku script, jelikož nemáme přístup k HTML dokumentu).

Kromě konstruktoru Worker existuje kontruktor SharedWorker, který založí pracovní vlákno, jenž má být sdíleno více rámy (nebo okny) aplikace.

Celá specifikace je v počátečním stádiu a výrobci prohlížečů se k ní postupně vyjadřují. Troufnu si odhadovat, že ačkoliv přináší velké změny, nakonec se do prohlížečů dostane, byť je pravděpodobné, že před tím ještě projde úpravami. S ohledem na to, že JavaScript je v prohlížečích stále rychlejší, začíná být srovnáván nejen s dalšími skriptovacími jazyky, ale třeba s céčkem, začíná být představa složitějších skriptů běžících na pozadí reálná.

W3C začleňuje HTML5 do validátoru

2008-08-26T07:54:00.006+02:00

Vývojář validátoru W3C Olivier Thereaux včera oznámil novou alfa verzi HTML validátoru, která přidává podporu pro HTML5. Interně je validace řešena voláním HTML5 conformance checkeru Henriho Sivonena.

Nová verze není zatím bez chyb, nerozpozná kupříkladu zjednodušenou deklaraci kódování dokumentu <meta charset="utf-8"> a nefunguje tlačítko revalidate, proto zatím stále zůstávám u Henriho nástroje.

Jakmile se podpora HTML5 dostane do veřejné verze na adrese validator.w3.org, odpadne psychologická bariéra pro experimentování s HTML5. Pokud totiž dnes na vašem webu použijete HTML5 (ať již k tomu máte jakékoliv důvody), můžete obdržet (a tedy nejspíš obdržíte) reakci, že váš web NENÍ validní. A vysvětlujte, že váš web validní JE, ale podle specifikace, kterou ten božský validátor zatím neumí.

Komu patří data atributy v HTML?

2008-08-21T11:11:00.011+02:00

HTML5 přináší data atributy. Jakékoliv značce můžete přidat libovolný počet různých atributů
data-cokoliv="vaše data",
ke kterým můžete přistupovat přes jednoduché API
element.dataset["cokoliv"].

HTML5 se tak snaží specifikovat (sjednotit), co někteří kodéři dělají již dávno (přidávají si vlastní datové atributy pro potřeby svých skriptů).

Pokud by se totiž nešvar vlastních atributů rozmohl, tak nejenže časem ubude validních stránek (to by až tolik nevadilo), ale objeví se počet konfliktů, kdy atribut používaný uživatelem A je v konfliktu s atributem frameworku B a obojí je v konfliktu s připravovaným atributem další verze značkovacího jazyka.

HTML5 tedy vymezuje hranice a říká: "S data-* si dělejte co chcete, ale nikam jinam už nesahejte." Z data-* atributů se tak stává místo s cedulí "Zde jsou lvi", kterému se validátory budou vyhýbat jako čert kříži.

Otázkou je, komu toto nově uvolněné místo vlastně patří. Specifikace k tomu říká:

Data atributy jsou určeny k ukládání dat patřících stránce nebo aplikaci, pro které neexistují vhodnější značky a atributy.

Vzpomínám si, že ta formulace měla uchovat data atributy čisté a nezaplevelené pro koncového vývojáře a měla být odvedena pozornost např. komunity okolo mikroformátů, aby je nevzala útokem. Toť idea.

Nebude asi překvapením, že se v diskusním listu mikroformátů objevily reakce "hurá, to se nám hodí" vedle reakcí "ne, to není pro nás".

Specifikace jen těžko určí, kdo má nebo nemá které atributy používat. Teprve čas ukáže, zda si nově objevenou zemi nějaký dobyvatel nezabere pro sebe. Při dnešním počtu JavaScriptových frameworků není problém, "zaplevelit" data atributy desítkami předdefinovaných názvů (a vemte v úvahu, že na jednom webu se často používá frameworků několik nebo alespoň jeden framework s několika pluginy) . Podobně, pokud by data atributy nakonec použily mikroformáty.

Je to trochu podobné se zavedením značky object (embed). Otevřela bránu do nové země, nikdo netušil, k čemu všemu může začít sloužit a dnes se zpožděním se zavádí značky video a audio, ačkoliv mohly být zavedené už dávno, pokud by se média od začátku necpala do nejsnazšího místa, kam to šlo, čili do objectu.

Data atributy jsou snadné místo pro rozšíření HTML, že snazší už být nemůže, ale to není jejich účel. Mají sloužit pro uchovávání dat, která mají význam pro kód koncové webové aplikace, nikoliv pro data, která budou mít význam napříč celým Webem.

A komu patří data atributy v HTML podle vás? Koncovým vývojářům nebo autorům frameworků?

Další čtení: John Resig: HTML 5 data- Attributes

Open Web podcasty nejen o HTML5

2008-08-19T09:12:00.014+02:00

Nedávno byla odstartována serie Open Web podcastů. Stojí za nimi Dion Almaer (Ajaxian), John Resig (jQuery) a Alex Russel (Dojo toolkit). První podcast byl věnovaný mj. HTML5, druhý podcast se věnoval JavaScriptu.

Jedná se o zajímavý zdroj informací (vedle rovněž nedávno založeného Standards Suck), tedy pokud vám nevadí, že jednou kromě rychlého pročtení článku musíte poslouchat půlhodinový až hodinový stream, abyste se něco dozvěděli (pokud spěchám, tak mi to pěkně vadí, tyhlety podcasty, ale pro zpestření je to zajímavé).

Zároveň na blogu WHATWG odstartoval Mark Pilgrim sérii týdenních článků, ve kterých shrnuje, co se právě okolo HTML5 děje.

O informace z oblasti webových technologií není tohle léto nouze.

HTML5 parser v JavaScriptu

2008-08-18T14:07:00.007+02:00

Henri Sivonen, autor experimentálního HTML5 validátoru (resp. conformance checkeru), přeložil pomocí Google Web Toolkitu svůj parser psaný v Javě do JavaScriptu. Na adrese livedom.validator.nu tak můžete snadno experimentovat s HTML5 parserem, aniž byste museli cokoliv instalovat.

Zajímavé není parsování validního kódu (zde výsledek asi nikoho nepřekvapí), ale právě parsování těch fragmentů HTML, které bylo v předcházejících specifikacích nedefinované. Nástroj není ani tak zajímavý pro webdesignery (ti si píší svůj kód stále stejně a zda prohlížeč akceptuje i jiný kód, jim může být v zásadě jedno), ale hlavně pro výrobce prohlížečů, autory parserů a knihoven pracujících s HTML.

Pokud se výrobci prohlížečů na HTML5 parseru shodnou (a je to skutečně možné, byť ne nevyhnutelné), bude se jednat o jednotný způsob parsování HTML.

Specifikace HTML5 parseru se stále dolaďuje a Henri svůj parser podle specifikace průběžně upravuje. Nejedná se o jediný existující HTML5 parser, existuje další projekt v Pythonu a experimentuje se i s Ruby nebo C#.

(Zdroj: blog.whatwg.org)

Firefox 3.1 s podporou videa, Opera zatím jen experimentální buildy

2008-08-12T22:42:00.008+02:00

Připravovaná nová řada Firefoxu 3.1 již podporuje HTML5 značky <video> a <audio>. Až donedávna byla jejich podpora dostupná pouze v neoficiálních verzích Firefoxu, nyní jej obsahují pravidelné vývojové verze řady 3.1. První stabilní verze řady 3.1 je odhadována na konec roku.

Podpora ve Firefoxu zahrnuje přehrávání formátů Ogg Vorbis (zvuk) a Ogg Theora (video) podobně, jako plánuje prohlížeč Opera.

Předpokládám, že se obnoví diskuse o nalezení společného kodeku, která se zatím veřejně nikam dál neposunula. Ian Hickson sdělil, že v tomto směru probíhají neveřejná jednání. Víc se neví.

Vývojář Firefoxu Robert O'Callahan tvrdí, že je třeba tlačit na Microsoft a Apple, aby implementovali Ogg rovněž (což nebude jednoduché ne-li nemožné), zároveň vývojáři Firefoxu pracují i na univerzální podpoře nainstalovaných kodeků na uživatelově počítači (skrze Directshow, Quicktime a GStreamer).

Zároveň i Opera uvolnila další experimentální build s podporou značek <video> a <audio>.

Když jsem se loni ptal Který prohlížeč první implementuje video?, tipoval jsem právě Operu, která s implementací začala jako první (odhadem již před rokem a půl!). K mému překvapení ji zatím předběhlo jak Safari, tak to vypadá, že brzy i Firefox.

Opera zatím nezařadila podporu ani do vývojových verzí a pouze jednou za několik měsíců vydá speciální vývojový build. Buď řeší nějaké implementační problémy nebo to má prostě jen nízkou prioritu.

Aktualizováno: Na komentář Applu k problematice kodeku upozorňuje server Ajaxian.

Proč v HTML5 není univerzální odkaz

2008-08-11T21:13:00.013+02:00

Eric Meyer již nějaký čas navrhuje začlenění univerzálního odkazu do HTML5. Tedy aby přidáním atributu href se mohla jakákoliv značka stát odkazem. Myšlenka to není nijak nová, její první návrh jsem našel již z roku 1994. Eric přistupuje k problému zodpovědně, sepsal use cases pro jednotlivé případy a naposledy vytvořil i zajímavé demo.

Nicméně tato vlastnost se do HTML5 s největší pravděpodobností nedostane.

Odpovědí na otázku: "Proč tomu tak je?" není (jak někdo posledně napsal v komentářích) neochota podobat se XHTML2, které univerzální odkaz obsahuje, ale zpětná vazba implementátorů.

Ian Hickson k tomu poznamenal:

Otázka globálního atributu href="" se objevuje znovu a znovu. Existuje pro něj řada oprávněných use case, např. možnost udělat odkaz ze všech buněk řádků tabulky nebo vytvořit banerovou reklamu jako jeden blokový odkaz.

Bohužel implementátoři mi znovu a znovu opakují, že globální href="" je špatný nápad a oni jsou těmi, kdo má poslední slovo, a proto se nedá svítit.

Ian Hickson kdysi pravdivě (a trochu smutně) prohlásil, že jeho moc jako editora specifikace HTML5 sahá jen tak daleko, dokud specifikuje to, co by implementátoři jinak stejně implementovali. Zamyslete se nad tím a pochopíte nejen tento příklad, ale i řadu dalších věcí okolo vývoje HTML5.

A pokud v (X)HTML univerzální odkaz opravdu chcete, zeptejte se vývojářů vašeho prohlížeče, proč jej v něm nelze implementovat? Ať vám pěkně vysvětlí proč.

Mezi dalšími přírustky jsou i outerHTML a insertAdjacentHTML

2008-08-11T08:40:00.004+02:00

Ve specifikaci HTML5 se dnes v noci objevily i outerHTML a metoda insertAdjacentHTML. Obě vlastnosti byly před časem zavedeny v Internet Exploreru a fungují pouze v HTML dokumentech, narozdíl od innerHTML, které funguje i v XML dokumentech.

Nenašel jsem zatím zdůvodnění, proč byly do specifikace zahnuty. Mám za to, že obě implementoval pouze a jen Internet Explorer. (Naopak třeba innerHTML bylo zahrnuto již dávno, protože je implementují i další prohlížeče a na webu se běžně používá.)

Ian Hickson ve specifikaci ponechává jen věci, o kterých je přesvědčen, že je prohlížeče budou implementovat. Proto buď má vyjádření od ostatních prohlížečů, že implementují i tato rozšíření, nebo na takové vyjádření právě čeká a podle výsledku případně obě metody opět odstraní.

Dostane atribut alt složené závorky?

2008-08-10T15:50:00.007+02:00

Diskuse okolo (ne)povinnosti atributu ALT u obrázků stále pokračuje, obě strany se stále nepochopily a nemají k sobě o moc blíže. V takové situaci: "Babo raď!"

Babská rada (i když jejím původcem je asi Ian Hickson s Davidem Baronem) se snaží o nový pohled, který má překonat onu spornou oblast, když obrázek neobsahuje textovou informaci, a učinit ji lépe přístupnou.

Tedy obrázek, který textovou informaci buď nenese (resp. nese, ale ta se nevztahuje k obsahu), nebo tato informace není prostě známá (např. uživatel nahrál sadu fotek z dovolené do fotogalerie a webová fotogalerie nezná textovou alternativu fotek, ačkoliv fotografie by textovou alternativu mohly mít).

V tuto chvíli konzervativní strana tvrdí, že je nutné buď zadat prázdný alt nebo jej něčím vyplnit (alt="Photo"). Druhá strana by alt naopak vypustila.

Ona babská rada snažící se o kompromis v takovém případě navrhuje alt vyplnit, ale vložit jej do složených závorek, např alt="{Photo}". Tím by alt byl poskytnut, ale je zdůrazněno, že neobsahuje textový ekvivalent obrázku (což mohou na základě závorek hlasové čtečky rozpoznat).

Použití ve spojení s novou HTML5 značkou figure, která páruje obrázek s textem by pak mohlo vypadat takto (zde je textová alternativa obrázku uložena ve značce legend a alt obsahuje pouze planý text ve složených závorkách):

<figure>
<img src="foto-2008-08-10-145.jpg" alt="{photo}">
<legend>Péťa překonávající pod stolem svůj osobní rekord v počtu vypitých piv</legend>
</figure>

Jedná se zatím jen o námět do diskuse. Uvidíme, zda pomůže celý spor vyřešit.

PersistJS pro překonání cookies

2008-07-16T08:22:00.007+02:00

PersistJS je JavaScriptová knihovna uchovávající (perzistentí) data na straně klienta. K tomu používá všechny možné prostředky od úložišť HTML5, přes Google Gears po Flash.

Knihovna nabízí jednotné rozhraní, programátor tedy nemusí řešit, jaké úložiště se ve výsledku použije, zda běží v prohlížeči s podporou HTML5 nebo zda se prostě použije Flash. Data se ukládají v jednoduché formě klíč + hodnota:

// create a new client-side data store
var store = new Persist.Store('MyDataStore');

// pretend data
var data = "pretend this is really long data that won't fit in a cookie";

// save data in store
store.set('saved_data', data);

Autorem knihovny je Paul Duncan. Verze 0.1 je první vývojovou verzí a autor přiznává, že se v ní ještě mohou objevovat chyby.

Knihovny jako je PersistJS pomohou elegantně překlenout období, ve kterém novinky HTML5 budou v některých prohlížečích podporovány a v jiných nikoliv. Pokud cookies pro vaše aplikace nestačí, doporučuji vývoj PersistJS sledovat.

(via Notes about PersistJS)

Značka video ve stromu Firefoxu, zatím ne v oficiálních verzích

2008-07-15T18:46:00.007+02:00

Podpora značek video a audio, kterou programuje Chris Double, se po měsících vývoje dostala do zdrojových kódů Firefoxu. Oficiální verze (ani noční buildy) podporu zatím neobsahují (je nutné provést vlastní kompilaci s parametrem '--enable-media'), ale jedná se o důležitý mezikrok pro začlenění do oficiálních verzí.

Pro ty, kdo se nemohou dočkat, připravil Chris Double pěkné video, ve najdete zajímavé ukázky spojení videa např. s SVG (zrcadlení a další efekty):

Lachlan Hunt v podcastu o HTML5

2008-07-03T12:00:00.000+02:00

Lachlan Hunt (Opera Software) poskytl rozhovor o HTML5 v podcastu severu Boagworld.

V rozhovoru přijde řeč na WHATWG, jeho spolupráci s W3C, na nové značky, které HTML5 přináší, zejména ty sémantické, dále na audio, video, canvas a také, které části HTML5 jsou již implementovány v prohlížečích.

Lachlan také vysvětluje, jaký je vztah HTML a XHTML v rámci HTML5:

So instead of having two distinct language which you can use we have combined them into a single language which share the same elements and attributes and everything and as much a possible and when the browser reads those file it produces and internal representation called the DOM

Můžete si stáhnout celý podcast (MP3, 27MB) nebo, pokud preferujete čtení (a nechcete poslouchat omáčku v podcastu okolo), si můžete celý rozhovor přečíst.

(via Interview about HTML5 on Boagworld)

Značka time a mikroformáty

2008-06-30T15:40:00.004+02:00

Nedávno se znovu rozhořela diskuse na téma vkládání data pomocí mikroformátů (viz BBC nasadilo a opět odstranilo mikroformáty). Stávající syntaxe využívající značku <abbr> a atribut title totiž snižuje v současných čtečkách použitelnost stránek, a proto se hledá alternativní řešení.

Do diskuse nad možným řešením napsal Henri Sivonen, podílející se na tvorbě HTML5, připomínku, proč není jako náhrada znažována značka <time> z HTML5.

Zájemci si mohou přečíst celé vlákno (stručně: značka <time> zatím nebude zvažována jako náhrada <abbr>, protože není validní v HTML4 a XHTML1 a mikroformátové komunitě se HTML5 zdá dosud příliš nezralé). A já rychle využiju situace k představení této značky.

<time>
Značka <time> je jednou z nových sémantických značek HTML5. Používá se jednoduše:

<p>Nahý exhibicionista s transparentem "HTML5 rules" proběhne Václavským náměstím <time datetime="2008-07-01 10:00 +2">zítra v 10 hodin</time>.</p>

Slouží k sémantickému vyznačení času, data případně obojího dohromady (značku <date> v HTML5 tedy nehledejte, vystačíte si s <time>).

Její jediný atribut datetime obsahuje strojově čitelnou variantu času (data) k lidsky čitelnému (human readable) údaji v obsahu značky.

Skrze DOM atributy date, time a timezone jsou přístupné jeho jednotlivé složky v podobě DOMTimeStamp (ušetří se tak krok s parsováním textové hodnoty).

Je vidět, že pro zápis časových údajů je značka <time> jako stvořená. Vlastně si nedovedu představit, že by mikroformátová komunita mohla přijít s něčím lepším (a že jsem moc zvědav, s čím nakonec příjdou).

Součástí HTML5 specifikace je <time> již hodně dlouho (odhadem několik let). Chce se mi spekulovat, že tam byla vložena, právě proto, aby časem vyřešila problém mikroformátů, ale okolnosti jejího vzniku budou hluboko v historii WHATWG mailinglistu a zatím jsem se k nim nedostal, takže kdoví.

Parsování URL součástí HTML5

2008-06-25T15:55:00.002+02:00

Ian Hickson nedávno do HTML5 zařadil sekci o parsování URL obsahující i zpracování těch neplatných zápisů adres, které prohlížeče všeobecně akceptují. Což je v souladu s myšlenkou HTML5: cokoliv je všeobecně akceptováno, mělo by být specifikováno, i pokud se jedná o zpracování neplatného stavu.

Ian se snažil zmapovat stávající zpracování adres v prohlížečích, ať již se jedná o adresy s mezerou:
http://example.com/hello world/
nebo o adresy obsahující znaky s diakritikou:
http://cs.wikipedia.org/wiki/Čeština

Ian poslal do mailing listu uri@w3.org dotaz, zda by se uvedené zpracování nemělo stát součástí URI specifikace namísto HTML5 specifikace, kam tak úplně nepatří.

Reakce byla negativní. Nikdo nechce specifikovat to, co není v původních specifikacích povolené. Proto tato část pravděpodobně zůstane součástí HTML5. Celou diskusi najdete ve vlákně Error handling in URIs.

(via URI error-handling in HTML5, and documenting the (real) Web vs. reinventing it)

Co přináší druhá pracovní verze HTML5

2008-06-20T12:30:00.002+02:00

Minulý týden W3C vydalo druhou pracovní verzi specifikace HTML5. Pojďme se letmo podívat, co se od první lednové verze změnilo. Na úvod ještě malé vysvětlení.

Co je to pracovní verze?

Pracovní verze (working draft) nevychází, jak by se někdo mohl domnívat, v momentech, kdy je dokončena některá ucelená část specifikace. Pracovní skupiny u W3C mají povinnost vždy po několika měsících pracovní verze zveřejňovat.

To je dobře, protože veřejnosti se tak nabízí stabilní dokumenty, které mohou studovat aniž by se jim měnily pod rukama (např. HTML5 specifikace se jen od tohoto pondělí do pátku změnila 14krát), odkazovat na ně a diskutovat je.

Na druhou stranu pracovní verze je pouhý otisk specifikace k určitému datu. Obsahuje body rozdělané (možná i rozepsané) a může obsahovat i konfliktní tvrzení (protože se změnila jedna část a nestihl ještě zaktualizovat zbytek specifikace).

Teprve, jakmile se u dokumentu objeví slůvko recommendation (existuje více jeho podob: Candidate Recommendation, Proposed Recommendation, Recommendation), lze chápat celý dokument jako konzistentní.

HTML5 specifikace a další

W3C vydalo 10. června tyto dokumenty:

HTML 5 - vlastní specifikace
HTML 5 differences from HTML 4 - souhrn novinek od HTML4
HTML 5 Publication Notes - změny od lednové verze

A co zde nenajdete:

WebForms2 specifikaci, protože o jejím osudu není dosud rozhodnuto

Pokud se o HTML5 teprve začínáte zajímat, podívejte se na HTML 5 differences from HTML 4, kde najdete to nejdůležitější a detaily pak můžete konzultovat se specifikací.

Pakliže vývoj HTML5 sledujete a zajímá vás, co se změnilo, pak dokument HTML 5 Publication Notes obsahuje detailní soupis veškerých změn. Jedná se de facto o čitelnější podobu diffu obou verzí specifikace. Uvedu stručný přehled.

Hlavní změny od lednové verze

Zaveden atribut reversed pro značku ol
Zavedeny atributy seamless a sandbox pro iframe
Zavedeny události beforeprint a afterprint
Zavedeny metody showModalDialog() a showNotification()
Zavedena kolekce document.scripts
Zavedení ruby anotací
Zavedena onload událost pro značku script
Vrácen atribut style
Značka font je nevalidní
Vrácen atribut target
HTML5 se vypořádává se začleněním MathML
Zavedeny datové atributy data-
Canvas je rozšířen o textové API
Rozšířeno API pro contenteditable
Změnilo se API pro DOM storage.
Přejmenováno globalStorage na localStorage
Změnilo se API pro zprávy mezi dokumenty
Změnilo se API pro event stream

Tolik asi základní změny. Kromě nich došlo k řadě úprav detailního popisu parsování HTML (většinou jen upřesnění reverzního inženýrství současných prohlížečů), a k řadě dalších drobností, které zde nerozepisuji.

(via HTML 5 Publications)

První zmínky o testu Acid4

2008-06-19T11:35:00.004+02:00

Dosud plně neodezněl rachot okolo testu Acid3, ještě jím žádný prohlížeč se zcela čistým štítem neprošel a už se objevují první zmínky o testu Acid4.

Tedy zmínky, spíš bych to nazval únik informací.

Jedná se o adresu http://www.hixie.ch/tests/evil/acid/004/, kam si Ian Hickson začal psát své poznámky ohledně testu Acid4. Někdo ji objevil a zveřejnil na Ajaxian.com. Docela by mne zajímalo, kde to objevili, protože tohle mým zdrojům zcela uniklo.

Následné informace proto berte s rezervou, a jen pro ty opravdu zvědavé (a ty, co se nestydí nakukovat do soukromých poznámek). Vy ostatní honem huš pryč!

Acid4 bude převážně vizuální test bez výrazného skriptování. Zaměří se na SVG, CSS a míchání jmenných prostorů, hlavní dokument pravděpodobně bude XML soubor s SVG kořenovou značkou.

Ian se v Acid4 tedy nejpíš zaměří na XHTML a další XML formáty.

Na jeho vznik si podle všeho ještě pár let počkáme:

Práce na Acid4 začne jakmile budou existovat buildy tří ze čtyř hlavních renderovacích jader, které testem projdou a bude ukončen a oznámen, až výrobci čtyř renderovacích jader oznámí, že opravili chyby nalezené v Acid3 (to může nastat mnohem dřív než se tato jádra skutečně dostanou do prohlížečů).

Pozn.: V první větě je zřejmě myšleno "jakmile 3 jádra projdou Acid3 testem", ačkoliv z přesné formulace vyplývá "jakmile 3 jádra projdou Acid4 testem", což nezní moc pravděpodobně.

A bez zajímavosti není ani seznam bodů, kterých se Ian chce u Acid4 vyvarovat (vychází zřejmě z některých kritik testu Acid3).

Poučení z Acid3
nezahrnovat minoritní chyby
nevyžadovat testy od jiných, psát všechny testy sám
zjišťovat feedback již od začátku od (t=0) bodu, jak veřejně, tak osobně od konkrétních lidí
zjišťovat feedback, které věci testovat
nevystavovat test v prvních fázích, aby se zabránilo lidem v odkazování, zatímco se řeší, co se má vlastně testovat
nezahrnovat do testu výkonností složku (ačkoliv jako zvláštní soutěž je to možné, pokud všichni odsouhlasí, že je to fér)
ať se jedná o pěkný obrázek

Toliko z poznámek člověka, jenž se pomalu ale jistě řadí mezi lidi, kteří nejvíce ovlivnili vývoj Webu a webových prohlížečů.

Je zajímavé, že se Ian, ačkoliv se veřejně nebojí vyjadřovat svou skepsi k XHTML, v testu Acid4 zabývá právě XML.

Já Iana trochu podezřívám, že se snaží vše načasovat, aby test, který bude vytvářet po tom, tedy Acid5, mohl vyjít společně s HTML5 specifikací a testovat tak HTML5 a XHTML5. Potom není s podivem, že se mezi tím věnuje XML. Na HTML není do té doby moc co dalšího testovat.

Co z HTML5 je ve Firefoxu 3

2008-06-18T14:05:00.010+02:00

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.

CSS exploit aneb proč na webu nemáme soukromí

2008-06-16T08:15:00.002+02:00

Tvorba specifikací je odpovědná věc. Jednou vytvořené specifikace budou platit roky a s každou chybou, která se do nich dostane, se můžou potýkat celé generace.

Chyby se do specifikací skutečně dostávají a často jsou neškodné, že si jich všimnou jen vývojáři prohlížečů, ale běžný webdesigner si s nimi hlavu neláme.

Jen opravdu výjimečně se objeví chyba, která má dopad až na koncového uživatele. Toho, který sedí v teple u svého prohlížeče, pohodlně si kliká a o zkratkách CSS nebo HTML nemá ani potuchy.

Největší chyba webových specifikací

Mluvím teď o chybě všech chyb, o tzv. CSS exploitu. Popravdě si myslím, že se jedná o historicky největší chybu, která se kdy do webových specifikací dostala. A přitom základní myšlenka vypadá zcela nevině, citujme z původní specifikace CSS1, odstavec 2.1:

User agents commonly display newly visited anchors differently from older ones. In CSS1, this is handled through pseudo-classes on the 'A' element:

A:link { color: red } /* unvisited link */
A:visited { color: blue } /* visited links */

Myslíte, že zavedení pseudotříd link a visited nemůže mít pro uživatele neblahé následky? Pokud ano, tak se šeredně mýlíte. Stejně tak se zmýlili i tvůrci CSS1. I když těžko jim to mít za zlé, v letech 1994-1996, kdy kaskádové styly přicházely na svět, ještě Web nebyl plný bezpečnostních problémů, a jak by taky mohl být, když samotný JavaScript byl teprv v plenkách (objevil se koncem roku 1995).

Dnes mi o CSS exploitu vyšel článek, pokud jste o CSS exploitu dosud neslyšeli a pokud si myslíte, že na Webu existuje soukromí, doporučuji si ho přečíst:

Pokud si myslíte, že stránka, kterou právě čtete, o vás nemůže nic zjistit, tak se mýlíte. S jistou pravděpodobností by pomocí tzv. CSS exploitu dokázala odhadnout, jaké vyhledávače používáte, které e-shopy navštěvujete (včetně kategorií, které vás zajímají), zda používáte internetové bankovnictví nebo PayPal, jestli nenavštěvujete politicky nekorektní stránky a mnohem víc.

Více se dočtete v článku CSS exploit a neexistující soukromí na webu.

Namočte se do HTML5 (prezentace)

2008-06-13T09:45:00.003+02:00

Lachlan Hunt a James Graham na @media 2008 v Londýně prezentovali Getting Your Hands Dirty with HTML 5 (nechtěl jsem to do nadpisu překládat doslovně).

Slidy z hodinové prezentace si můžete prohlédnout ve formátu PDF (30 MB). Shrnují základní principy vývoje HTML5 a některé hlavní myšlenky specifikace. Časem bude zveřejněn i záznam celé přednášky.

Offtopic: říkám si, zda někdy taky dokážu vytvořit tak vtipné slidy jako Lachlan s Jamesem, protože ty jejich se mi moc líbí.

(Via @media 2008 Presentation Slides a HTML5 Presentation at @media 2008)

Nastavení komprese exportu z canvasu do JPEG

2008-06-06T15:45:00.004+02:00

Rozhraní canvasu obsahuje metodu pro export svého obsahu do obrázku (ukázka). Jedná se o metodu toDataURL() s volitelným parametrem, který určuje typ vygenerovaného obrázku. Specifikace vyžaduje, aby prohlížeče implementovaly export do formátu PNG, další formáty jsou volitelné.

Prohlížeče, které canvas implementovaly (S.O.F = Safari + Opera + Firefox), export do PNG již podporují, Firefox navíc podporuje export do formátu JPEG.

Anne van Kesteren včera oznámil, že Opera rovněž plánuje podporovat JPEG a hledá možnost, jak by mohli vývojáři nastavit kompresní poměr vytvořených obrázků, více viz příslušné vlákno, ve kterém se řeší, zda by se to mělo dít pomocí atributu canvasu nebo pomocí dalšího argumentu metody toDataURL.

Canvas se tak postupně zdokonaluje a stává stále mocnějším nástrojem (viz např. nedávné začlenění funkcí pro renderování textu). S tímto přístupem se stávající hračky jako je kupříkladu Pixastic prototype online nástroje pro editaci fotografií pomocí canvasu časem stanou skutečně použitelnými aplikacemi pro práci s obrázky (aplikaci grafických filtrů již zvládají, chyběl právě ten kvalitní export).

O HTML5 na TechCrunch

2008-06-06T11:45:00.003+02:00

Na serveru TechCrunch nedávno vyšly dva články zabývající se HTML5.

Ten první The Next-Gen Web: Browser Storage Support se zabývá offline úložišti a soustředí se na jejich podporu v prohlížečích. Většina obsahu článku nebude pro čtenáře tohoto blogu velkou novinkou. Na konci ve shrnutí autor Nik Cubrilovic píše:

Je velmi neobvyklé, aby se nová technologie jako lokální úložiště v prohlížečích dočkala tak široké pozornosti a byla převážně založena na jediné specifikaci.

Což je hezké, ovšem zatím se ještě nesjednotily rozdíly mezi implementacemi v Google Gears a v blížícím se Internet Exploreru 8, byť se na obojím snad pracuje.

U lokálních úložišť a cachování (pozn. překl. myslí tím offline aplikace) je tak zatím vítězem otevřený standard. Alternativní řešení pravděpodobně vymizí nebo se přizpůsobí a implementují stejné API.

Druhý článek se jmenuje The Next-Gen Web: HTML5 - Will We Ever See A Real Standard?, vrací se do historie a spekuluje nad tím, zda HTML5 náhodou nepotká stejný osud jako HTML3 (to je historická verze HTML, která zcela propadla, nikdy se nedokončila a neimplementovala).

Ačkoliv se předpověď autora článku může vyplnit, přesto zde vidím několik rozdílů. Snaha o vytvoření HTML3 neprošla, protože ho v zásadě nikdo nechtěl implementovat, prohlížeče (hlavně ty dva) mezitím válčily mezi sebou a nějaká standardizace je zas až tak nezajímala.

Dnes je situace jiná, prohlížeče HTML5 implementovat chtějí a nejenom že chtějí, oni ho již pomalu implementují. Není náhodou, že odhadem více než polovina celé HTML5 specifikace se dočkala nějaké implementace alespoň v jednom prohlížeči, byť průnik zatím není příliš velký (myšleno průnik jako část implementovanou komplet všemi prohlížeči).

Ve zbylých bodech (rozsáhlost specifikace, trvání její přípravy) lze dát článku pravdu. Je ovšem otázkou, zda pro neúspěch HTML3 byly klíčové právě tyto body nebo naopak to, co jsem popsal já výše.

A citace ze závěru článku:

Historie Webu nám ukazuje, že je tu obvykle jen jeden vítěz, uživatelé pravidelně migrují k jedinému vyhrávajícímu řešení, které se samo prohlásí za standard.

Je pro mne zajímavé sledovat, jak se zprávy o HTML5 pomalu přestávají objevovat jen na stránkách určených pro "technologické hračičky" a HTML5 je pomalu objevováno i v bussiness prostředí (slovo pomalu jsem ztučnil, protože ten posun v povědomí bude trvat dlouho; určitě neproběhne v tomto roce nejdříve tak v roce příštím).

Tisk v HTML5

2008-06-06T09:35:00.001+02:00

Včera do specifikace HTML5 přibyla krátká sekce Printing. V té se podrobně definuje, jak se má prohlížeč zachovat při volání metody window.print() nebo vyvolání tisku z uživatelského rozhraní prohlížeče, a zavádí události beforeprint a afterprint.

Pro mne jsou tyto události novinkou, ale podle všeho jsou již implementované v Internet Exploreru, tak je možná někdo znáte. V mailing listu WHATWG bylo jejich začlenění již kdysi navrhováno.

Tyto události mohou připravit dokument k tisku tam, kde kaskádové styly pro tisková média nestačí. Jako jednoduchý případ je uvedeno např. zobrazení aktuálního času při tisku ve stránce. Já bych byl rád, kdyby nás dokázaly zbavit i odkazů à la Vytiskni mapu na www.mapy.cz (a nejspíše i na většině dalších map a podobných aplikací), resp. ať tam ta tlačítka třeba i zůstanou, ale nechť vyvolání tisku z prohlížeče vyvolá stejný efekt jako tyto odkazy.

Během vyvolaného dialogu k tisku musí prohlížeč po proběhnuté události beforeprint buď zastavit všechny změny stránky (tedy JavaScript, animace obrázků, pluginy etc.) anebo si zapamatovat jejich podobu v momentu, kdy uživatel vydal pokyn k tisku (aby prohlížeč nakonec nevytiskl neco jiného, než co uživatel chtěl).

Firefox 3 a canvas s textem

2008-06-05T13:15:00.005+02:00

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.

Chceme jednotné výchozí CSS pro všechny prohlížeče?

2008-06-04T12:50:00.001+02:00

Včera se v HTML WG objevil zajímavý návrh. Justin James v e-mailu s předmětem Proposal: Default style definitions for elements navrhuje, aby se součástí HTML specifikace stalo i ustanovení výchozích kaskádových stylů pro všechny prohlížeče.

Myšlenka je to určitě zajímavá (snad každý webdesigner se minimálně jednou podivil, proč má každý prohlížeč výchozí styly jiné), otázkou je, zda by byla v dnešním spektru různých platforem a zařízení se svými zvyklostmi a omezeními rozumně realizovatelná.

Vývojář Gecka Boris Zbarsky ji odmítá, Anne van Kesteren tvrdí, že Ian Hickson má v úmyslu se tomu věnovat.

Jsem zvědav, jaké další názory se v diskusi ještě objeví. Pokud vás to zajímá, sledujte příslušné vlákno, přečtěte si i loňské vlákno na stejné téma a wiki stránku HTML Issue: Default Style Sheet, kde se mají sbírat náměty k řešení.

BTW jistý předpis již existuje jako součást CSS specifikace, ovšem nejedná se o žádné nařízení (prohlížeče se podle něj chovat nemusí a ani tak nečiní).

Offline webové aplikace v kostce

2008-06-04T11:59:00.007+02:00

W3C včera vydalo dokument shrnující základní informace o offline webových aplikacích. Autory Offline Web Applications jsou Anne van Kesteren a Ian Hickson.

Dokument je velmi krátký (vytištěný se vejde na čtyři A4 stránky) a neobsahuje nic, co by nebylo součástí HTML5 specifikace. Jeho hlavním účelem je představit základní myšlenky tohoto nového konceptu (SQL5, offline manifest, online/offline události).

Očekávám, že do budoucna se podobných dokumentů objeví více. Přeci jen každý nemá čas číst celou dlouhou specifikaci, a tak jsou taková shrnutí velmi přínosná.

(Via blog.whatwg.org)