HTML5.cz a překlad knihy Dive into HTML5

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

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.

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

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

• FAQ
  
• Z referencí tvůrců loga
• Rozhovor s tvůrcem
• Twitter HTML5 loga
• Otevřený dopis od WaSP
• Kritika od Tanteka Celika
• Reakce z druhé strany
  

Flash proti HTML5

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)

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)

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

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.

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

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

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

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

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.

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

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

Zápis vypadá jednoduše:

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

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

<input type=file multiple>

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

Více: ukázka, specifikace.

Sáhněte si na soubor

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

Z JavaScriptu bude pomocí nového API možné zjistit nejen název takového souboru, jeho typ a velikost, ale také přistupovat k jeho obsahu a to třemi asynchronními způsoby (dnes už je takový trend dělat všechny náročnější operace asynchronně, aby nedocházelo k zamrzání stránky v prohlížeči) :

• readAsBinaryString
• readAsText
• readAsDataURL
  

Zvolená metoda se váže na typ obsahu a co s ním chcete dělat. U textových souborů použijete readAsText. Pokud chcete pracovat s obrázky, ale nemáte v úmyslu je měnit, zvolíte readAsDataURL (následně do vlastnosti můžete img.src nastavit přímo tuto hodnotu a obrázek se zobrazí) atd.

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

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

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

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

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

Úvod do HTML5 od Brada Neuberga

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

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

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

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

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

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.

Noční buildy Firefoxu obsahují parser HTML5

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

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

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

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

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

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

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

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

Související

• Help Test HTML5 Parsing in Gecko
  
• John Resig: HTML 5 Parsing

Konkurent YouTube od ThePirateBay bude postaven na HTML5

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

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

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

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

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:

• Server-Sent Events
• Web Storage
• Web Workers
• The Web Sockets API

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.