Mark Miller on Securing JavaScript: More Qcon Live Blogging

Google Research’s Mark Miller is presenting a talk on Caja and web security. He emphasises that this is all bleeding-edge; no current browser fully supports this yet.

There are a ton of attack vectors for browsers, as shown on the Caja wiki. There are spec vulnerabilities, implementation vulnerabilities, and an ongoing arms race emerges. Mark shows a table of numerous variables for each browser, where the variation is not just wild but more or less random. The attacker only need to find one vulnerability here.

Perhaps the ongoing cat-and-mouse game means there’s something wrong with the whole identity-centric paradigm. Instead, maybe we can look at access control – don’t worry about who’s sending the request, worry about if the request has the correct level of access.

Mark walks us through the history of web kludges – JSON and Comet for cross-domain calls and streaming, respectively. HTML5 gets us towards a truer web of distributed objects, which all leads towards a symmetric network.

Safe Mobile Messages: Uniform XHR

Uniform as in “Uniform Resource Location”.

The proposal is for the server to ignore browser’s “helpful” extras.

Authorise based on payload. HTTPS URL or request body – info the requestor knows.

HTML5 allows servers to waive response protection using “Access-Control-Allow-Origin: *”.

Mobile Code

How do you mix coded from multiple untrusted sources into the same frame?

To solve this problem, we bring other security models to the world of JavaScript. With EcmaScript 3, Caja had to perform complex, server-side, translation with a runtime overhead.

The lessons of this effort were taken to the Ecmascript committee, and accordingly, EcmaScript 5 is one of the easiest OO languages to secure, instead of one of the hardest, as was the case previously.

Security as Extreme Modularity

This view treats security as an extreme form of modularity (ie the mutually suspicious components are seen as modules). Vulnerability is a form of dependency…so improving security also helps in other aspects, ie. makes the architecture cleaner.

So we marry up these closely related principles: * Software Engineering Principle of info hiding: Need to know. * Security Engineering Principle of least authority: Need to do.

These are the rules enforced: * Memory safety and encapsulation * Effects only by using held references * No powerful references by default

Objects as Closures

javascript

  1. function makeCounter() {
  2.   var count=0;
  3.   return {
  4.     incr: function() { return ++count; }
  5.     decr: function() { return --count; }
  6.   };
  7. }

A record of closures hiding state is a fine representation of an object of methods hiding instance variables.

With “use strict”, we can enforce freezing of values. So if you have object A which depends on object B, object A can freeze properties of object “B” to make sure the reference doesn’t change. An important aspect of this is the ability to feeze a prototype.

For now, we have the “initSES.js” library. It monkey patches away bad non-standard behaviours, freezes whitelisted global variables…among other measures.

There’s a concept of membranes (wrappers) to encapsulate/secure message passing. e.g. if you don’t trust object X, you can make a read-only version of its return value. It’s also possible to wipe out what’s inside the membrane at some later stage, if desired. Even if that thing had references to external objects, only what was inside the membrane will be wiped.

“Classy HTML”: A Speculative Design Pattern about Classes and Composition

This is a pattern about Classy HTML.

Classy

ooo posh

No, not THAT “Classy”. This “Classy”:

HTML

No, not THAT “HTML”. This HTML:

The Classy HTML Pattern

Pretty simple: Store important app state as classes in your root (“html”) element.

For example, consider a countdown app. Its significant (from a UI perspective) state can be summed up as being one of three things: “fresh” (app just started), “counting”, “done”. Your app is, in effect, a state machine transitioning between those states according to a set of rules. (Acknowledging that reality and subsequently managing those state transitions with JavaScript can also be an interesting problem ripe for a parsimonious design, but let’s just take that for granted here.)

You would set your HTML class as “fresh” to begin with, and then programmatically switch it over to “counting” or “done” as the app plays out.

Your CSS reflects it:

  1. /* We choose the default case to reflect the most common case, ie "counting" or "done" */
  2. html.fresh .welcomeMessage { display: none; }
  3.  
  4. html.fresh { background: white; }
  5. html.fresh .counter { opacity: 0.3; }
  6.  
  7. html.done { background: red; }

The important thing here is the selector idiom, which can be summed up as “html.state descendentSelector“. We’re styling our classes all the way down, based on the overall application state.

I haven’t done too much of this kind of design, but I can see myself doing more of it as apps get more complex and everything becomes single-state. I’ve been contemplating refactoring the Hacker News Reader along these lines, since (thanks mostly to Paul), it now has sliding panels, and so can effectively be in three states: stories, story (one story above the list of stories), comments (comments above one story above the list of stories).

I guess all this is obvious to CSS design pros, i.e. it’s a natural consequence of the CSS model, but I’ve not thought about doing it much and I mainly got the idea from this FOUC trick, which uses this pattern, but in a very restricted and specific way. The main insight really is that single-page apps usually have a small number of key states which can affect the entire UI.

As with any good pattern, it raises further questions:

  • Should you use “class” or an HTML5 custom “data-something” attributes. I think it’s in the spirit of HTML/CSS to use “class” to represent a state, so that’s fine. And CSS attribute-based support won’t work on older browsers, so that’s another tick for “class”. BUT custom attributes have the distinct advantage that you can be more precise about what kind of state you’re referring to. So while it could just be “data-state”, it could also be “data-phase” or (a boolean) “data-active”. Which takes us to the next question …
  • Should you use more than one type of state? I think for complex apps, yes. And you can then use custom data attributes to manage the type of class. Or you could just use them as a list of free-floating class names on the HTML tag.
  • Should you use multiple selectors, e.g. [data-phase=”counting”][data-authenticated=”false”] to be more precise? In general, I think no. It would lead to ridiculous combinatorial complexity, so it’s better to treat each state variable – if you must have more than one of them – as being orthogonal. That said, there are probably special cases where it makes sense and fortunately modern CSS makes it easy to pull off.
  • What’s the base case? Should it be the initial state or the “typical” state?
  • Looking at the bigger picture, when do you switch pages versus switch states inside the app?

Async Talk on Chrome Extensions and Chrome Web Store

I gave a talk last night at Async, a fortnightly meetup for Brighton’s ever-thriving JavaScript community, organised by the talented Prem Rose. The talk was on Chrome Extensions and the Chrome Web Store, and was a mashup of our separate GDD talks on those topics (GitHub), some live coding, and some new stuff now that the Web Store is live…though the main focus was Chrome extensions.

Slide Deck: Chrome Extensions and the Chrome Web Store

A fun part of the talk was live coding. I haven’t done it before, but I felt it went well and was definitely worthwhile. The project was an extension to show the latest blog posts on the Async website, in a toolbar button (aka browser action). Chrome extensions are a lot easier to write than most people imagine, so it was an effective demo to start with a new directory and make it happen. For the record, here’s the extension we hacked up in 15 minutes or so: async.crx. (Styling was not the main focus of this exercise 🙂 ).

I also did something I’ve been meaning to do for a while: A Venn diagram to illustrate the relationship between extensions, packaged apps, and hosted apps:

Finally, I had a good question about detecting if you’re website is running as an installed app. I couldn’t remember the details, but they are here:

javascript

  1. if (window.chrome && chrome.app && chrome.app.isInstalled)

(Updated the snippet following Johan’s suggestion in the comments.)

WebWait Upgrade: Deletion, Quick Entry of Multiple Sites

I made a couple of upgrades to WebWait this week.

First, you can now delete entries. This is useful for curating a set of results, since you can save a result set for others to try out, or for later analysis and comparison. If I get requests, I may also allow users to re-order the results for that reason too. You can only delete a trial when it is complete, i.e. when all calls to it have been made. This is not ideal, but would require significant rework. Again, I’ll respond to feedback on this one.

Second, you can now enter multiple URLs in the input field, separating them by space. I received a request from a Dzmitry Markovich, who wanted to time hundreds of websites at once, and figured I should support it. It’s an undocumented feature intended for advanced users, as I don’t have time to think about how to integrate it into the UI without compromising the simplicity of the design (e.g. with a text area; I should at least mention the feature in the FAQ, which is now ancient.) In the case of someone wanting to enter dozens or hundreds of websites, they need to cut-and-paste into the input field.

Funnily enough, both of these features had previously existed, but were removed when I overhauled the architecture to make way for the benchmark saving feature. The new architecture, being based on semantic events, made the deletion feature rather easy. The multiple-URL feature was also quite straightforward, as it would be with any architecture.

This is the latest of four updates in WebWait’s lifetime of as many years. Slowly but surely :).

Is this what the App of 2015 looks like? HTML5 + CoffeeScript + Less + WebStore + PhoneGap + Apparatio

My weekend project was a Hacker News Reader (source code). It works on Chrome, Safari, and Opera. Sorry, Firefox doesn’t work at present, reasons why speculated below. Mostly started this project because I want one with Twitter integration, but also to play with a few technologies, which I did. Among things explored and demonstrated:

  • Server-Less App The app is entirely browser-side. The server serves only as a repository of static files. Content comes from the iHackerNews unofficial API, by way of JSONP, the protocol we’ll still use for cross-domain calls until CORS becomes eminent in the hopefully not-too-distant future.
  • CoffeeScript. The app logic is written in CoffeeScript, and compiled to JavaScript in the browser with coffee-script.js.
  • Less. The UI styling is written in Less and compiled to CSS with less.js.
  • Chrome Web App. The app is also a hosted web app on the Chrome Web Store, which is to say (a) it can be discovered by users of the store; (b) it can be installed into the New Tab page of Chrome, for convenience sake; (c) if I wanted to, and added some extra server smarts, I could charge for it. I wrapped it up as an app with Paul’s super-handy Appmator utility.
  • Mobile HTML5. Although I didn’t (yet) optimise the site for HTML5, I did make it available on mobile, with the right icons for being added to the Home Page, and used Build.PhoneGap.com and Apparatio to roll it up as a native mobile app.

CoffeeScript

I wanted to try out CoffeeScript. While I’ve been skeptical about languages which are said to “compile down” to JavaScript, as if JavaScript was a complicated tangle of 1s and 0s rather than the high-level language it is…CoffeeScript is different. It’s more like JavaScript++ as the name implies. While I do find JavaScript to be pretty good, its syntax can get too verbose. Especially for closures, where you have too many curly braces and “function” keywords getting in the way of the actual logic we care about. You can also be more expressive with keywords like “unless”.

As ~98% of code people write never sees high-scale production use, I like to opt for quick and dynamic over tedious and “it just feels like the right way to do it”. So I employed coffee-script.js to compile dynamically, in the browser when the web app loads, instead of pre-compiling it on the command-line. Doing it dynamically means I can just type some code and reload the browser page, about the smallest possible debug-test cycle that is possible.

I found it slow-going at first, because I ran into some coffee-script.js gotchas and learned a few things about the language on the way:

  • Keep CoffeeScript in a separate server. Although CoffeeScript supports inline CoffeeScripts in your HTML (<script type=”text/coffeescript”>…here is my script….</script>) – perfect for quick hacking), I recommend you stick them in a separate file (<script type=”text/coffeescript” src=”myscript.coffee”></script>. I can’t explain exactly why, but when it was inline, things were note very deterministic and I found my CoffeeScript script was getting executed three times!
  • Use a server, not file:/// URIs. As with less.js, CoffeeScript mocks the browser’s script-downloading behaviour, using XMLHttpRequest to pull down any scripts specified in “text/coffeescript” script tags. Unforuntately, Chrome doesn’t let you XHR one file from another file, so you need to set up a server, if only to serve these static files over HTTP.
  • Don’t bother with window.onload (or jQuery intializer). I *think* coffee-script.js guarantees any CoffeeScripts you provide will be executed after the window has already loaded. I haven’t confirmed this, but seems to be that way on Chrome, Safari, and Opera. OTOH, the app doesn’t work on Firefox – CoffeeScript isn’t executed at all – and this may be related.
  • Declare before you use. A consequence of the previous rule is that your initialisation sequence will run in the order you specify it. This is different to the usual JS situation where you make a window.onload handler, which might call things that you’ve declared further down in the file. So in the code further down, note that I declare “show” before I call it. Pretty obvious, but JS habits and lack of descriptive error messages meant it caught me out.
  • Whitespace matters. There are no semi-colons and no braces here; similar to Python, whitespace dictates structure. However, you can also use parantheses to keep things on the same line, so I didn’t find this threatening to concise code.
  • Use “window” for global. Declarations like “x=5” out in the open will *not* make global variables; and nor is there a “var” keyword. The only way to hook into global space is to explicitly reference the “window” object; e.g. “window.x = 5”.

How’s the code look? See for yourself, CoffeeScript keeps it pretty tight. I couldn’t find many examples of jQuery-CoffeeScript combos, so this will hopefully be useful in that regard:

javascript

  1. storiesTemplate = _.template($("#storiesTemplate").html())
  2. show = () ->
  3.   $.getJSON "http://api.ihackernews.com/page?format=jsonp&callback=?",
  4.     (storyInfo) -> $("#stories").fadeOut () ->
  5.       $(this).html(storiesTemplate(storyInfo))
  6.       $(this).fadeIn()
  7.  
  8. show()
  9. setInterval show, 10*60*1000
  10.  
  11. $(".story").live "click", (ev) ->
  12.   return if $(ev.target).closest("a").length
  13.   window.open($(".url", this).attr("href"), "hackernews"+Math.random());

  • Less fails silently. Unfotunately, you don’t get error messages, so develop things gradually and be prepared to undo.

Less

If I was going to take a sip of CoffeeScript, it would only be fair to munch on a slice of Less too. If CoffeeScript is JavaScript++, then Less is CSS+. It’s really augmented CSS, because you can present a regular CSS stylesheet and it will be valid Less too. That’s not true at all about CoffeeScript; a typical JavaScript script has Buckley’s of passing the CoffeeScript compiler.

The other thing they have in common is JavaScript compilers. Which is not the case with SASS for instance.

Less talk:

  • Same XHR issues. As with CoffeeScript, the Chrome cross-domain restriction means you have to use a server even though the files are static. Also, it doesn’t seem to be possible to include Less stylesheets inline, or to get hold of the less compiler, which I think is a shame if true.
  • Silent fail. If any Less doesn’t parse, the entire stylesheet won’t be applied, and there’s no error message.

So some downsides, but the upside was a cleaner stylesheet with less redundancy. Gradient macro makes the ridiculously verbose gradient declarations completely DRY:

  1. /*****************************************************************************
  2.    MACROS
  3. *****************************************************************************/
  4. .linearGradient(@color1:#ccc, @color2:#ddd) {
  5.   background-image:-webkit-gradient(linear, left bottom, left top, color-stop(0, @color1), color-stop(100%, @color2));
  6.   background-image:-moz-linear-gradient(center bottom, @color1 0, @color2 100%);
  7.   background-image:-o-linear-gradient(center bottom, @color1 0, @color2 100%);
  8.   background-image:linear-gradient(center bottom, @color1 0, @color2 100%);
  9.   background-color: @color1;
  10. }
  11. .postedBy:hover, .commentsLink:hover span { .linearGradient(#fa0, #f80); }

Elements can be nested in their parent selectors:

  1. .commentsLink,.commentsLink:visited {
  2.   position: absolute; top: 50%; right: 1em; height: 1em;
  3.   ...
  4.  
  5.   span {
  6.     ...
  7.     border-radius: 0.3em;
  8.   }
  9.  
  10. }

… and so can pseudo-selectors:

  1. .story {
  2.   padding: 0.5em 9em 0.5em @leftIndent;
  3.   border: 1px solid black;  border-bottom-width: 0;
  4.   background: #fff6f6;  cursor: pointer;
  5.   position: relative;
  6.  
  7.   &:hover { .linearGradient(#fc0, #fa0); }
  8.  
  9.   &:last-child { border-bottom-width: 1px; }
  10.    
  11. }

And you can do cross-browser CSS calculations today:

  1. .commentsLink,.commentsLink:visited {
  2.    ...
  3.   margin-top: -0.5em-@commentsLinkPadding;
  4.  
  5.   span {
  6.     ...
  7.     padding: 0em + @commentsLinkPadding;
  8.   }
  9.  
  10. }

Chrome Web Store

This is a full-screen, focused, app which therefore meets the criteria for Web Apps I outlined in Thinking In Web Apps. (It would be more so if it showed the actual stories and comments in the app too, but that’s something for later.)

So it made sense to submit to the Chrome Web Store. Fortunately, my colleague Paul Kinlan had the gall to attempt building a web app that packages up Chrome apps … and then he actually pulled it off! Appmator asks you for the address of your web app, asks a few other basic questions, and then makes a Zip file you can drag to your desktop and upload to the store. All in all, a 30 minute submission to the Chrome Web Store and a nice way for people to discover your web app. I would only recommend this for true “Apps” as opposed to general websites, and ideally those apps should be tailored to a full-screen experience.

Anyway, it’s on the store now – Hacker News landing page.

PhoneGap, PhoneGap Build, Apparatio

The app is NOT optimised for mobile at this time, but the cool thing about HTML5 is, for the most part, it “just worked” when I pointed iPad and Android phones to it. Some things need improvement, but this is good to see.

For exploration purposes, I decided to build it as a native mobile app anyway. I was lucky enough to receive beta invites for PhoneGap Build and Apparatio, two web services which let you do PhoneGap without actually installing anything on your PC. I built this app with both products.

Apparatio, which I used previously, worked nicely and I was able to get a native Android app.

PhoneGap Build supports GitHub like Apparatio, but also allows uploading a zip file. I actually had a problem pointing it at my GitHub repo (as with Apparatio, it needs to provide clearer instructions on exactly what form of URL is required). After I uploaded the zip file, it showed me a dashboard of 4 packages being built, and just went ahead and built each of them. Nice and simple!

Android, WebOS, Symbian, Nokia. Conspicuous by its absence is iOS, which Apparatio does support.

DropBox on my Macbook and Galaxy made it easy to copy the APK downloads to my Galaxy and install it. The Apparatio one took some time to download initially, but worked fine. The

Other Notes

Block-level “a” element, NOT. HTML5 makes it possible for “a” elements to be block-level, i.e. to include other tags including other “a” elements. This would be ideal for the Hacker News Reader UI, where the entire story block is a link to the story itself, but the block also contains links to comments and authors. It turned out to be legal in modern browsers, but with blatantly wrong layout, as someone else found earlier. Shame as I had to introduce considerably more JavaScriptCoffeeScript and CSSLess.

InnerHTML, Templating, and Live(). Seems like every project I do these days, I’m building dynamic content with innerHTML, as opposed to DOM manipulation. The first reason is I’ve become accustomed and satisfied with templating, and see it as a growing trend thanks to language-agnostic formats like Mustache as well as server-side JavaScript. (Though in this case, it’s a pure browser-side app.) So make a template and stick it on the page with innerHTML (or jQuery’s .html() ). The second reason is jQuery’s live() command makes it easy to handle events against the newly formed elements, which was previously a pain with innerHTML().

Setting text size. As you can see, text size varies with the number of points a story has. The relevant line appears in the template:

font-size:<%= Math.log(Math.log(Math.max(s.points,10))) %>em;

Using a log scale ensures a story with 2000 points isn’t 2000 times bigger than a story with 2 points. To dampen the effect further, which I think is important in mobile displays, I used a double-log and applied a minimum threshold of 10 points.

Future Things

There was actually an itch to be scratched here, beyond trying out various tech. Specifically, I’ve been wanting a mobile HN reader that would: (a) tweet; (b) quickly mark for instapaper reading, and ideally when I’m offline. (It would show the latest stories it saw when online, and cue them up for later…in general, I wish more offline apps would support cueing things like Tweets and Read Laters for when you’re back online.)

Fin.

So is this the Web App of 2015 or not?

There are definitely elements here that are not in wide use now, but will be in wide use by 2015. The whole “write once, run many” aspect of HTML5 is just getting wheels. It’s now clear that Apple won’t dominate the landscape by 2015, so regardless of their ever-fluctuating stance, HTML5 will be able to power the apps of the majority of smartphones and tablets…not to mention the possibility of apps on TV, cars, watches, washing machines, etc etc etc. (Can you tell it’s been CES week?)

And with HTML5 being able to power these apps, we’ll need ways to fit them into the App ecosystem, and that’s where PhoneGap and friends fit in. As I’ve said in various places, I always found it painful to have to set up Eclipse, PhoneGap SDK, and so on just to make a native app from HTML5. These are the things HTML5 developers don’t want to do, and the PhoneGap team is well aware of it, hence their PhoneGap Build effort. Apparatio provides relief in the same way and we can expect the same from others, especially so in light of Heroku’s high-valuation acquisition bringing attention to the whole idea of cloud programming. GitHub is also a vital component of this vision becoming reality. The next step will be to automate deployment into the stores, hopefully something that app-hungry stores will be happy to facilitate.

The Chrome Web Store is a related concept aiming to “app-ize” we apps. Mozilla is investigating a similar idea, and we’ll see a lot more of it in the next few years too. Some people say “but it’s just a bookmark”, an understandable reaction, but I think people are starting to get it now. It should only be an app if it really is an app, ie. if the underlying URL is really a media-rich, focused, app rather than a big collection of information and hyperlinks. And the Web Store is not just a place where you can buy and install apps; it’s also a directory where you can find all the cool apps on the web, with screenshots and reviews and comments to help you decide if they’re worth trying out.

Offline is important in the app story too (although this app doesn’t (yet) do any offline). You don’t type in URLs when you’re on a plane, but you do click on app icons to launch them. So offline web apps need an app-like presence to meet user expectations.

How about those languages, CoffeeScript and Less? CoffeeScript seems promising and I’ll definitely be using it more. At the same time, I’m weary because I feel like JavaScript may be “good enough” and CoffeeScript becomes a maintenance problem if others need to see your code. But the leap is not a big one.

As for Less, I’m more convinced it’s the way to go. We nowadays have an absurd proliferation of “-webkit-” “-moz-” “-o-” “-msie-” prefixes and the various syntaxes to go with them. It’s for good reason, but it’s also as much an affront to the DRY principle as any agilist could ever fear, and it’s unfortunate the standards don’t provide better support for dealing with this sort of thing. Likewise, the need for variables/constants and calculations. Less allows for all of that, and in a way that will work on legacy browsers even when some of these features do come about. So, yes, I’ll be committing to Less in the future.

What’s very cool about both Less and CoffeeScript is the JavaScript frameworks. It’s ideal for starting off a project, and when performance gets to be an issue, you can easily switch to the compiled version after that.

Finally, I’ll mention that templating is a design pattern that’s also going to be big in 2015. There’s much more framework support these days and it’s easy to use the same templates on the browser and the server.

Congratulations jQuery, winner of Open Source JavaScript Libraries Award

I participated as a judge for Packt Publishing’s open source JavaScript libraries award. Today, they’ve announced the winner: jQuery. Open source JavaScript is stronger than ever, and all of the entrants in the award have made great strides in the past year. Runners-up Raphaël and Mootools deserve great praise for the work they’ve put into both their products and community.

Packt’s press release is below and includes a quote from this blogger.

jQuery wins the 2010 Open Source JavaScript Libraries Award

Birmingham, UK. 18 November 2010

Packt Publishing is pleased to announce that jQuery has won the inaugural Open Source JavaScript Libraries Award category in the 2010 Open Source Awards. The Award is a new category introduced to the Open Source Awards this year, featuring libraries of pre-written JavaScript controls which allow for easier development of RIAs (Rich Internet Applications), visually enhanced applications or smoother server-side JavaScript functionalities.

“On behalf of the entire jQuery Team, let me first say thanks to Packt Publishing for this award.

I’d also like to give a huge thanks to the community of designers and developers that use jQuery daily and felt the urge to vote for jQuery as their favorite JavaScript library. We’ll use this prize to further the development of the jQuery Project.” Said Ralph Whitbeck, jQuery core team member.

“While jQuery hasn’t undergone any radical change in the past year, the project has continued to evolve at the same frenetic pace and the 1.4 release included a wide range of small but important improvements.” Added Michael Mahemoff, Google developer advocate, HTML5/JavaScript specialist and one of the judges for the 2010 Open Source JavaScript Libraries category. “jQuery covers all bases as its performance is high priority, it is easy to use, has a huge community, great documentation, and an excellent plugin ecosystem.”

While jQuery occupied the top spot in the 2010 Open Source JavaScript Libraries category, the other two extremely popular finalists Raphaël and Mootools tied and both projects will be awarded the first runner up position.

With this announcement, the 2010 Open Source Awards has two more categories left, including the Open Source CMS category, for which results will be announced November 19th.

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

Kiev GTUG

I gave a talk on HTML5 and ran a #chromekyiv hack day, where people built HTML5 apps and Chrome extensions. It was the first time anyone had participated in a hack day and it worked fine; I think hack days are more about how you present them than whether they suit any particular place or culture. Mainly, as with HTML5 Game Jam, I aimed to very clearly explain the process, and very explictly tell them I’m here to help, and then wandered around a bit; as people won’t often ask for help if the organiser’s head is buried in their laptop.

We had about 6 hours of hacking, completing at the fine hour of 10pm, and 2 minute presentations. Around 20 attended the talk and 14 hacked till the bitter end. Got some footage on the Flip which I’ll try to upload at some point. Kyiv GTUG managed to sneak past Kyoto GTUG for #1 Pulse spot

in the process :). Nice job!

The winner was an excellent Chrome extension from @yasik, @shooshpanchick, and, and @webdizz. Scrapes addresses from any web page and shows them on a map. I also realised when I met him that I have used @yasik’s Delicious extension in the past (his was the first for Chrome). Watch his GitHub as they work towards a stable version of this extension.

There were also some nice entries from others. A CSS3 photo gallery and hard-to-describe visual effect involving your name being shown at a million angles and opacities. A wikipedia looker-up using the new context menu capability (pro tip: here’s how you get the selected text). A syntax highlighter for any programming language, using IDEOne’s web service. A localStorage-powered colour setter.

For my part, I presented Control Freak, a GreaseMonkey like extension I started writing a couple of days earlier, and completed to the point of usefulness at the event. Basically a very lightweight way to tweak JS and CSS on the current page, using a browser action (ie address bar button), which I’ll post more about soon.

ChromeKyiv Photos

#ChromeKyiv Tweets

Ukraine PyCon

This was a fairly large regional PyCon, with a number of talks in English to encourage attendance. It was nice timing being immediately after Casual Connect, and the Pythonistas graciously welcomed a talk about a foreign language in a foreign language.

I gave a talk on Web and Apps, similar to my earlier FOWA talk, but updated to include recent HTML5 gaming activity and a little overview on what HTML5 adds to the basic technologies of HTML, CSS, and JavaScript. The point is to show that HTML5 is an incremental improvement; you’re still dealing with the same language and programming paradigm.

#UAPyCon Tweets

Full Page Slides

Thanks to all the organisers.

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

  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

8 HTML5 Features You’ve Never Seen Before [LWS Talk]

I had the honour of speaking at London Web Standards this week along with Opera’s Patrick H. Lauke. @otrops, @twitrnick, and the rest of the volunteer organisers put a ton of effort into each event and it shows.

At this event, I presented “Eight HTML5 Features You’ve Never Seen Before”:

It’s the visual elements of HTML5 that everyone is watching right now, but the present surge of web evolution encompasses much more than that. This talk will overview several important technologies in the “everything else” basket of HTML5 and related technologies: application caching, client-side storage, cross-origin resource sharing, websockets, ping, session history, workers, and geolocation.

The new means of presentation – CSS3, Canvas, SVG, Video, etc. – are a perfect complement to all of this new functionality, allowing it to be visualised and interacted with in fun ways.

Here are the slides.

And a favourite CORS slide:

The Video

Other coverage (thanks all):

Live Blog (thanks @flexewebs)

Notes from Steve Workman

More sketch from Justin Avery:
Sketch Note #lwsdeep HTML5 8 Things