HTML5 in Kiev

I’ve been in Kiev, Ukraine, this week, where I was fortunate to attend several events. The developers in this country and this region are super-talented, and I’m glad I was able to meet many of them directly.

Casual Connect

As with CC Seattle, there’s a big focus on social games right now. They are not only better for distribution – the viral nature – but often more profitable due to revenue sources which have no/little relevance in a single-player context. Namely, status-improving virtual goods; status-improving level advancement by way of automating/bypassing the grind; and, controversially/riskily, improving player capabilities.

I gave the following presentation on HTML5 Gaming. Fortunately, the HTML5 Game Jam we ran a couple of weeks earlier provided great evidence that it’s here and real, and I was able to make use of that in the examples. (I also came up with the idea of an iFrame player for these slides; so you can click on some screenshots to replace them with an iFrame showing the game. This is raw and needs more work, e.g. a big play button for starters.) All this emphasises the importance of micropayments/in-app payments for the social gaming segment.

The biggest concern game developers have with HTML5 is graphics capability. Handling a hundred avatars real-time on the screen at once, that kind of thing. I hope to work with a few of them to get some useful data and feedback for the browsers.

HTML5 Game slides

Including HTML Files from Other HTML Files, on the File:// System


“I wont be sending an officer because your not in any danger at all. You have obviously just put a blanket on a dog while it is sitting in your car and taken a photo. “

I still have a passion for web apps that run on the file system. It’s an extremely easy development model and extremely flexible. You can send a file (or set of files) to anyone and be confident they can open the files and run your web app, regardless of their operating system and without imposing on them the requirement of setting up a server. Furthermore, they can stick it on a share drive and BAM, guerilla multi-user system. I’ve had the habit long before I developed for TiddlyWiki but my time with TiddlyWiki focused my attention on the benefits and taught me a number of Single-Page App (SPA) hacks which most web developers are still oblivious to.

And let the SPA hacks roll on …

As I start to think about resetting the slideshow framework I’ve been randomly sniping at conferencesrecently, one thing I’d like to do is the idea of a file per Master Slide, containing all of the HTML, JavaScript, and CSS. This is more or less how TiddlyWiki themes work, and a very neat modularisation tactic.

Unfortunately, HTML – bless it – can include JavaScript (<script src="something.js">) and CSS (<link href="something.css"> etc), but not HTML (which would look something like <div src="something.html"> in my dreams). So what are the options for pulling in one HTML file from another HTML file:

  • Server-side includes: We’ve long had server-side includes. I powered my homepage from this less-than-stellar technique for modularisation around 15 years ago. The problem is none too hard to derive from their name. Server, I don’t want one.
  • XMLHttpRequest: We could make a XHR call and actually this is possible from file to file. Unfortunately, Google Chrome (and maybe others?) sees each file as belonging to a separate domain, making it impossible, and other browsers may issue a warning or confirmation, making it obtrusive.
  • File APIs: Again, we could use the magic of $.twFile to read the other file. But this relies on browser-specific hacks and they have to be degraded to a separate Java applet, which requires a proper Java installation, in the case of Chrome, Safari, Opera, and others. Firefox uses Moz-specific API and IE uses ActiveX, which are good but also incur warnings and may be blocked by firewalls. Still, it’s not a bad solution. The extra Java applet is a big downside in TiddlyWiki, because you suddenly need to send around two files instead of one, but here I’m already assuming there’s a bundle of files to be sent around.
  • Outputting HTML inside JavaScript: Since we can read Javascript, we could just spit out the HTML from JavaScript. The benefit here is it works, and works for the most ancient of browsers. But it would require a lot of string manipulation, which would look minging and be unmaintainable, and I massively value elegant code (or at least, the possibility of it). Many times I have wished JavaScript supported Here Docs, but alas, it doesn’t :(. The best you get is a long sequence of lines ending in . Unacceptable. You can also achieve this kind of thing with E4X, but that’s not widely supported.
  • Hiding HTML in JavaScript or CSS: I’ve considered tricks like embedding the entire HTML inside a JavaScript or CSS comment, but the problem is the same reason we need JSONP; when you source a JS or CSS file, your app feels the effects of it, but your code doesn’t get to see the source. I’m still holding a candle for the possibility of some CSS hack, like based on computed style, which would let you trick the browser into thinking the background colour of a button is an entire HTML document or something…which would be worth doing just for the sake of being insanely ace.
  • Or. iFrames.

Thinking it through, I decided iFrames are your friend. You embed the file to be included as a (hidden) child iFrame. This can work in a couple of ways.

The parent could read the DOM directly:

javascript
< view plain text >
  1. var dom = document.querySelector("iframe").contentWindow.document;
  2.     document.querySelector("#messageCopy").innerHTML = dom.querySelector("#message").innerHTML;
(The child contains message element, the parent contains messageCopy.)

This works on Firefox, but not Chrome, because Chrome sees each file as belonging on a separate domain (as I said above, wrt XHR). So we need to make a cross-domain call. We could be AWESOME and use the under-loved Cross-Origin Resource Sharing (CORS) capability to make cross-domain XHR calls, but in this case, it doesn’t work because it involves HTTP headers, and we’re doing this with pure files.

The solution, then, is another kind of iFrame technique: Cross-domain iFrames. It’s been possible to do cross-domain iFrame communication for a while, but fortunately, modern browsers provide an explicit “HTML5″ API for cross-domain iframe communication. I tested it in Chrome, and it works. On Files. Yay.

Under this paradigm, “index.html” contains:

  1. <script>
  2.   window.onload = function() {
  3.     window.addEventListener("message", function(e) {
  4.       document.querySelector("#messageCopy").innerHTML = e.data;
  5.     }, false);
  6.    document.querySelector("iframe").contentWindow.postMessage(null, "*");
  7.   };
  8. </script>
  9. <h1>Test parent</h1>
  10. <div id="messageCopy"></div>
  11. <iframe src="included.html"></iframe>

while “included.html” contains:

  1. <script>
  2.   window.addEventListener("message", function(e) {
  3.     e.source.postMessage(document.getElementById("message").innerHTML, "*");
  4.   }, false);
  5. </script>
  6. <div id="message">This is the message</div>

Point your spiffy HTML5 browser to index.html and watch in glee as the message gets copied from included to includer. I wasn’t sure it would work, because certain other things – like Geolocation and Workers – simply don’t work in all browsers against the File:// URI, even though they probably should. (Probably because the browsers keep mappings of permissions to each domain, and these systems assume the domain is served with HTTP(s).)

This technique will also degrade to older browsers using those “pre-HTML5 hacks. (As the Romans used to say, Omnis enim API HTML V, aequivalet HTML V pre-furta..)

So I’m glad this technique works and intend to use it in the future, nicely abstracted with a library function or two.

HTML5: The Platform Apps Have Been Waiting For

I just finished my FOWA talk, explaining the technologies of HTML5 that are making it possible to develop rich web apps. There are three things I should mention:

  • London in a tube strike is not pretty, until you realise you’re in 28 Days Later, and suddenly it’s ace.
  • I am posting my slides below. They are based on a slide framework that I trend to stitch and mend with each presentation. So they are still very alpha! But getting to be awesome for authoring. Also, I tend to use the biggest-size images available, so download may be slow.
  • Thanks to Carsonified for doing an amazing job making sure everything was taken care of, and the crowd for their energy, and for actually making it in to the venue on this challenging day of travel.

HTML5: The Platform Apps Have Been Waiting For (full-page version)

–>

In terms of questions, we had time for three – one was about which payment solutions are possible on the Web Store (any – it’s open – but the web store provides solutions which should help developers); one was about making native apps (Web Store doesn’t support native apps as such; but tools like PhoneGap let people create native apps targeting iPhone/Android/etc); and one was about whether Application Cache (and, I assume, other features under discussion in the presentation) are HTML5-specific versus Google-specific etc. I mentioned that I want to avoid the HTML5 debate in this talk and I’ll define it here as the spec and everything else going on around it. It’s a good point though to be clear that Application Cache and the other general technologies I discussed are based on open standards.

Twitter Feedback (via List Of Tweets:

  • Amazing Google Chrome experiment site using #html5 goodness http://bit.ly/cRV3WQ #fowa Mon Oct 04 09:07:34 +0000 2010 from Jas
  • Chrome Experiments http://bit.ly/HDM7w <-- #html5 Not your mother's Javascript! #fowa Mon Oct 04 09:10:22 +0000 2010 from Jas
  • Chrome App Store looks kinda cool. #fowa #google Mon Oct 04 09:18:13 +0000 2010 from jacksonj04
  • payments for web apps – according to #google #fowa chrome app store is the solution http://bit.ly/a7rBot Mon Oct 04 09:21:54 +0000 2010 from timanderson
  • Whoa! Proper geek exodus to Michael Mahemoff’s HTML5 talk at #Fowa Mon Oct 04 08:46:54 +0000 2010 from Jas
  • Huge welcome from a packed room at #FOWA for @mahemoff Mon Oct 04 08:48:47 +0000 2010 from sammachin
  • apps are not applications say Michael Mahemoff #google #fowa Mon Oct 04 08:49:05 +0000 2010 from timanderson
  • HTML 5 talk by @mahemoff from Google #fowa #yam Mon Oct 04 08:50:25 +0000 2010 from WebAndTech
  • Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:54:19 +0000 2010 from codepo8
  • RT @codepo8: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:55:03 +0000 2010 from mheap
  • #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:55:32 +0000 2010 from codepo8
  • RT @codepo8: #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:56:44 +0000 2010 from Paul_Kinlan
  • Christian Heilmann: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security: http://bit.ly/aRzGgm Mon Oct 04 08:56:59 +0000 2010 from __UBI__
  • #Fowa #Mahemoff “the proof is in the pudding” what does that mean? Mon Oct 04 08:57:11 +0000 2010 from llaisdy
  • Suffering catastrophic sense of humour failure as it looks like I’ll miss @mahemoff’s session at #fowa. £#^$ you, London transport. Mon Oct 04 08:58:38 +0000 2010 from philhawksworth
  • HTML5: The Platform Apps Have Been Waiting For – Michael Mahemoff – Google. http://twitpic.com/2uk62j Mon Oct 04 09:00:43 +0000 2010 from lewisking
  • Michael Mahemoff (Google) HTML5 web apps: #NewTwitter, Gmail on iPad, and lots of new games and now even video. Even fonts. #FOWA Mon Oct 04 09:00:57 +0000 2010 from Hagoleshet
  • Michael Mahemoff giving his talk on html5 using http://www.html5rocks.com/ at #FOWA Mon Oct 04 09:04:38 +0000 2010 from kaosbeat
  • The Wilderness Downtown explained… Getting great ideas from @mahemoff http://ow.ly/2NV7N #FOWA #yam Mon Oct 04 09:06:49 +0000 2010 from WebAndTech
  • @mahemoff recommends studying local storage API for prototyping so you don’t need to work with servers when doing quick hacks #fowa #easy Mon Oct 04 09:13:45 +0000 2010 from kaosbeat
  • Props to @mahemoff for being the first to skirt around the definition of #html5 at #fowa. Let’s #focus Mon Oct 04 09:18:14 +0000 2010 from codepo8
  • 4 things web apps need according to #google #fowa: local storage, application cache ,locally installable, payments Mon Oct 04 09:13:40 +0000 2010 from timanderson