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.

Lesk a bída HTML5 videa

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

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

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í

• Neoficiální zprávy o Internet Exploreru 9. Na pořadu jsou SVG, CSS transformace i canvas
  
• Co přinese IE9? Možná víc, než bychom čekali
  
• Mých 60 minut s Internet Explorerem 9
  

Google spouští HTML5Rocks

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

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

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

Už i Vimeo experimentuje s HTML5 videem

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.

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

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:

1. 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.
   
2. 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ř)

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

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?

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.