Hello.

I have learnt a lot of the last couple of days about inter-window and inter-iframe communication. I documented some of my frustrations about Web Messaging API’s and an attempted work around. For you to be able to pass data into a window (that isn’t on your domain) so that it is available before the onload event fires in the opened window, the only sane way I have found is to set the window name via window.

I have been working on a rather cool project recently that initially used a lot of WebMessaging (postMessage etc) to talk between all the components. However, even though these API’s look simple and easy to grok there are some bizaare limitations and usage of them is frustrating to say the least. Ignoring the fact that Chrome passes structured clones, and Firefox passes strings, that is a simple difference to resolve. It is not even the fact that WebKit supports MessageChannels and Entangled Ports and no one else seems too.

This is a story all about how my life got flipped turned upside down….. wait what?!?! I can’t start a blog post with The Fresh Prince. Last week, when I was still in my 20’s, I wrote a blog post about HTML5 History API needing a new event. This came about because the LeviRoutes framework would work better if it could understand when state had been pushed via History.pushState. Whilst investigating pushState and adding some tests to the LeviRoutes framework I wanted to be able to simulate an “onpopstate” event.

I love the HTML5 History API, it makes developing applications with a consistent URL scheme across server and client super simple, however it doesn’t come without its problems. When developing the LeviRoutes URL routing framework it became obvious that we need some changes to the specification as-is. The Mozilla documentation reports that onpopstate is called whenever the history object changes, unfortunately this is not the case, and is not the case with the spec either, the HTML5 Spec indicates: “The popstate event is fired in certain cases when navigating to a session history entry.

Whilst developing our latest app (https://github.com/PaulKinlan/ioreader) for a Google IO, we ran into several large is limitations with AppCache and HTML5 History that I wanted to share (and at somepoint hopefully solve). Putting the current discussion of the issues with AppCache aside for a couple of minutes, there is no provision in HTML5 History to include pages "pushStated" into the current App Cache GroupConsider this flow: We have a multi paged app with pages A and B when rendered from the server sharing the same AppCache and thus in the same group.

I have this bizarre mixed feelings about SVG, I loathe it and love it at the same time (according to urban dictionary the word is loave) and I hate myself for it - okay, hate is a strong word. I constantly feel frustrated by its complexity, requirement for tooling (have you tried to create a path by hand) and half-arsed integration into the web of today.  I see the <svg> element much like I see the <object> tag, that is a boundary that rarely if ever should be crossed by mere mortals, a semi-permeable barrier where only through reverse osmosis can we wrangle some of the elements in our usermode.

One of the many question that we didn't get to answer in our talk - Mobile web development: Zero to Hero - is "How long did it take to develop the app?". Luckily, we have an answer: The first commit of the project was on the 3rd of March, but that was mainly just a simple README file, the first commit of the server was 25th of March which is when we really started working on the code and began taking our ideas and basic concepts into a fully fledged solutionYou might think that just over a months worth of work went into this (it was, in theory), but it is a little more complex than that.

We had an awesome question by Pamela Fox for our Google IO talk - Mobile Web Development: Zero to Hero. In summary the question is "How can you use the Google Fonts API on mobile while optimizing performance? (Both visual + # of requests)" - which is interesting because on the Desktop it is not something you particularly worry about, but in mobile it is one of the most important things you need to consider - bandwidth, latency and visual aesthetics.

Another question that we didn't get to answer in our talk - Mobile web development: Zero to Hero - is basically the premis of the entire talk. We believe that in a large number of cases that it is entirely possible to build applications using one semantic document structure, a large swathe of common core logic whilst specializing for a given formfactor. From our talk, you can see that the User Interface is optimised for smartphone, tablet, desktop and TV - we believe that there are qualitatively different user interaction patterns in each form that it is important that you optimise for the different experiences, but for the developer experience it is not easy (or possible in some cases) to keep having to build one new app for each category of device that you want to target.

We had an awesome question for our Google IO talk - Mobile Web Development: Zero to Hero - that we didn't get time to answer live.How do we deal with the storage constraints imposed by modern browsers. The answer is simple, App Cache is used mainly to store program code, that is just the CSS and JS (and also the page that requests the AppCache), our application never got that large.

A question in our IO Talk: Mobile Web Development: From Zero to Hero was with regards I will say this, I love LawnChair - I have used it a couple of times and it makes getting data in and out of your application very easy, it is based on the premis that you need to store objects against a key, and then get it out again, it allows you to use a richer querying syntax, but in many cases (as with our IO Reader app) you don't need anything more complex.

Telling people about your web app in the Chrome Web Store is just as important as making your landing page rock. The more people that you can drive to your detail page the better your application will do, but you want to do it in a targeted way. For this reason I created Badgemator – an app that creates badges for you to put on your website. It is about a month old, so why am I telling you now?

If you follow me on Twitter – @Paul_Kinlan – you will know I yap on a lot about many of my projects on Github. This post is no exception, I want to introduce LeviRoutes, a client-side JS routing framework that is loosely based on a Rails like approach to URL handling. There are plenty of frameworks that do this already so why did you create this? I hear you ask. Well it is pretty simple.

About 2 months ago I announced to the world a project called Web Intents (http://webintents.appspot.com/) as a way to allow client to client service discovery and communication over existing supported Web technologies, that is IFRAME's and SharedWorkers. There is a definite problem on the web that if you want to talk to an app, you have to integrate your client and service with 3rd party services. This is bad for the user, your application imposes limits on the services you let the user interact with.

* I will caveat this whole post with the a hefty disclaimer that this only works on the Dev Channel of Chrome and could change significantly over time. Chrome introduced the notion of background pages to packaged apps and extensions. Background pages allow the app or extension to run without a UI surface – this is pretty cool because it allows for some really great use-cases that you don’t get with plain web applications; for example you can poll Twitter for updates that mention you and receive an alert via a Desktop Notification about the update.

We recently announced that the Netherlands will be one of the countries that will have the Chrome Web Store available with integrated support for Dutch sellers.On the 2nd of March 2011 starting at 7pm the Dutch GTUG will be holding an event at Google Amsterdam about HTML5 and the Chrome Web Store. I will show you some new cool stuff in HTML5 and related technologies and talk to you about how you can use the Chrome Web Store to reach new users.

That went by a lot faster than I thought it would.  Today (February 1st) completes my full first year in Google. It has been a crazy ride. Google is like no place that I have worked before, and I can honestly say it has been an amazing first year, I have met so many amazing people that I can’t count.  It is pretty amazing that I work for a company that is talked about everyday by billions of people on the planet.

As a part of my “resolutions”, I promised that I would get out of Google UK HQ and meet and work with developers more closely. Myself and @mahemoff should be working from @Techhub (Here) this Thursday (13th of Jan 2010). So if you are about in the area I would love to meet you.  I should be there from 09:00 to about 15:30.

There isn’t much to see here just yet, but I am just writing this as a test harness for a simple commenting system that I am developing using Buzz affectionatly named commently. Maybyly I am taking the naming too far, but this is a simple service that allows you to embed comments into your blogging platform. The comments are synchronized with Buzz based on the feed that you push to Buzz.

As always, I am a little late getting a blog post out, but here is my year in review (a very quick summary). I am going to post a "Tech Review" of my thoughts next. The most important thing that happened this year for me is the birth of our second boy (Benjamin) on the 28th of June - he is doing well and is a very cheeky chappy. It is pretty amazing watching kids grow up and learn to do things.