There is a lot of chatter about Mozilla considering implementing some webkit specific prefixes - I encourage everyone to read "Platform/Layout/CSS compatibility"

Browsers need to:

• Fucking drop experimental prefixes. It's unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.

• Non-production ready browsers should support experimental prefixes, production ready releases should not. If it's Chrome 16 - the stable version - experimental support should not be baked in. The properties should be full available without the prefix.

Permalink | Leave a comment  »

Chrome just got Web Intents support in Dev and Canary builds (18 onwards).  This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps.

{
  "name": "Share to Gmail™",
  "version": "0.0.0.2",
  "icons" : {
    "16" : "favicon.ico"
  },
  "intents" : {
    "http://webintents.org/share" : {
       "type" : ["text/uri-list"],
       "title" : "Share to Gmail",
       "path" : "/launch.html"
    }
  }
}

Permalink | Leave a comment  »

Permalink | Leave a comment  »

We have a huge problem on the web today. If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user.

We have a solution!

In December 2010 I announced a project called Web Intents whose goal was to allow developers to build applications and services that could work with each other, but not need to explicitly know about each other – the concept has heavily inspired by the Intent system in Android, although the API bore no resemblance. It would allow you to build applications using just the functionality your cared about, and then delegate the other functionality to the users preferred choice of service.

After some conversations, I moved to try and support Web Introducer as a specification over Web Intents. For one reason or another this didn’t quite work out so I decided to plug away at revising the WebIntents work that I started back in November.

It turns out there is a lot of interest internally with the idea of Web Intents and how it can work in modern browsers. We set up a small crack team and after a flurry of work, speccing and prototyping how we think it might look we have put a prototype API on to Github. Have a play, it is really easy to get started.

So what changed?

A lot as it happens. It is not the same as the initial project that I experimented with, although the goals are the same. We have an objective to make the developer experience of the API so painless that most developers can start integrating with applications in 5 minute of reading the spec – in fact we want it so that most developers can just copy and past examples and it will work with their service. We have tried to drastically reduce the API surface and make it so there is literally only one or two lines of code you need to start an activity.

Service registration has been made even easier that my initial project through the use of a new tag, for example:

<intent
  action="http://webintents.org/share"
  type="text/uri-list"
  href="share.html"
/>

This small tag, that is included in the head of your application will signal to the browser the intention to handle a “share” action for a selection of URI’s (think “share this page”), and will register it in the system so that the user can choose it when a client application wants to provide “share” functionality in their app.

When the service is chosen by the user, and the service is loaded the intent data is passed to the open application and is available on the window.intent object.

For clients to initiate an Activity it is easy too. Simply declare an intent and start the Activity as follows:

var intent = new Intent();
intent.action = "http://webintents.org/share";
intent.type = "text/uri-list";
intent.data = "http://paul.kinlan.me";

window.navigator.startActivity(intent);

The system will take care of the service resolution for the action and compatible data formats and give the user the choice of using their favorite application to handle the “share” intent.

I have only just touched the surface of what you can do with the API. There are a lot of things that you can do with the API over and above what I have described in this 5 minute overview. A selection of examples can be found at http://examples.webintents.org/ where we show you how to build applications that solve some common use-cases. I particularly like the cloud kitten service provided by the “pick” example.

We are working with Mozilla to define a common approach to solving the challenges that web integrators face today. We are interested in hearing your thoughts and we are still thrashing out the API so bits of it might change but the intent is still the same.

My closing thoughts are: “This project will fundamentally change and improve the way we build applications on the web today for our users.”

Permalink | Leave a comment  »

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

Client:

var w = window.open("list.html", "some data");

Service:

window.onload = function () {  alert(window.name); };

Now that we can pass data between the windows, you can quickly imagine that you stringify a JSON object on open and parse it in the opened window. Pretty simple.

The good news is that the work-around works in FF, WebKit and Opera as is, but not IE.

To get it working with IE, it takes a few of hacks so I thought it best to document them here.

When you open a window via window.open, the second parameter is the name, in IE it must only contain [A-Za-z0-9_], this means that you have to base64 encode the JSON object for it to be able to be sent across, but that is not enough because Base64 encoding can only use certain characters. Base64 will also likely include an == at the end, which is not an allowed character.

However, IE doesn’t include a btoa and atob function for managing base64, so you will also need to find a library to use.

To encode the data I used the following:

var winname = window.btoa(
  unescape(
    encodeURIComponent(JSON.stringify(obj))
  )).replace(/=/g, "_")
var w = window.open(e.target.href, winname);

To decode the data I used the following:

var obj = JSON.parse(window.atob(window.name.replace(/_/g, "=")));

Pretty hacky, but it seems to work.

As always, if anyone has a better suggestion, or there are any obvious flaws let me know.

Permalink | Leave a comment  »

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. These we can work around in sane ways.

The normal developers flow is as follows: open a window/iframe, get a reference to that window, send it a message, have the frame or window handle the message.

Client App:

var w = window.open("test.html");
w.postMessage({ data: "some more data"}, "*");

Service App: test.html

window.addEventListener("message", function(e) {
  // Do something with the data
}, false);

This would be pretty simple and intuitive, something that nearly every developer would be able to pick up in an instant. But this isn’t the case, if you want to send a window a message you have to wait for it to load – which might be a logical assumption, but given that if the page you are opening is outside the origin of the opener, you can’t easily tell when it loads. So the current solution is on the host page to postMessage back to the window.opener, and for the opener to handle the message.

Client App:

var w = window.open("test.html");
window.addEventListener("message", function(e) {
    if(e.data.state && e.data.state != "ready") return; // do nothing.
    // Send data
    e.source.postMessage({ data: "some more data"}, e.origin);
}, false);

Service App: test.html

window.addEventListener("load", function(e) {
    // tell the opener that it is ready to receive messages
    e.source.postMessage({ state: "ready" }, e.origin);
}, false);

window.addEventListener("message", function(e) {
    // Process data from opening window.
}, false);

This is bonkers! Developers just want it to work.

There is a hack that allows you pass data to a window so that it is available to the window as soon as the script starts executing. It is probably not safe nor is it likely to be secure. When you open a window, you can pass it data immediately using the name parameter on window.open()

window.open("test.html", "{ data: 'ABC123' }");

And then on the opening page, you can read it back.

var data = JSON.parse(window.name);

There are problems here though:

• We have no real proof of where the data came from, we can check window.opener but that is not enough
• We have to ensure that the window.name is cleared down as soon as we parse it, because it will be available for the life time of the application.

This is a quick hack, that allows the opened window to read the data that was passed to it as soon as it opened.

What are your thoughts? Have you come across these limitations? Have you solved them in any other interesting ways?

Permalink | Leave a comment  »

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.

Let’s just quickly digress with a little bit about HTML DOM events. HTML defines a rich series of events that are fired when a user clicks on something, the page loads or….. well let’s just say there are hundreds of events. Not only do the events get triggered when the user or system does something, but the developer can easily simulate events. If you want to click on a button via script. Simple:

var evt = document.createEvent("MouseEvent");
var anchor = document.getElementById(......);
evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false,

false, false, false, 0, null);

anchor.dispatchEvent(evt);

Why is this programatic dispatch important? You can build individual tests that are responsive to the events that would fire to user events without having to build a system that tries to automate the UI by say, managing the mouse pointer through hardware control.

Digressions aside, I was building tests that would test my HTML5 History handling logic without me having to physically invoke a History.pushState command. In summary, separating the physical navigation from my logic.

var evt = document.createEvent("PopStateEvent");
evt.initPopStateEvent("popstate".....);
window.dispatchEvent(evt);

This should have worked. Instead all I got was:

var evt = document.createEvent("PopStateEvent");
DOMException

Which if you read the Event specification is what occurs when an Event type is not implemented. I quickly jumped across to Firefox and tested the same code. It worked. So it must be a bug in WebKit.

Now, this is where my real story starts, and what I hope will demonstrate the power of Open Source software.

I was in a bind. I could raise a bug and hope someone might pick it up at some point in the future, or I could raise a bug and try to fix it myself. I chose the latter. I didn’t think it would be hard – after all the Event system is already in WebKit and PopStateEvent is already implemented, it is only the hookup with createEvent that didn’t.

Where do you start? I started by downloading the latest WebKit code and building it. In all this process took longer than the actual fix.

Once I had a build, I decided to create a very simple test case to prove that it is still broken. With this in hand, I had a quick peek at the Webkit code. Google Code search is your friend here, I just searched for “PopStateEvent” and it returned a list of important places to look.

Inspecting PopStateEvent.cpp and PopStateEvent.h, I could see that there was a create and initPopStateEvent methods so I was pretty sure I was in the roughly the correct place. I also knew that createEvent is on the document object in the DOM, so I did a quick search for createEvent and there was a file called “Document.cpp”, this looked promising. A quick search in Document.cpp highlighted the area where the events are created, and there was a suspicious lack of PopStateEvent.

Bingo!

I quickly raised a bug, on http://bugs.webkit.org/ detailing the error with a simple test case attached, and then went about fixing the code. Raising the bug seemed to take longer than the fix, which amounted to adding in a condition for the type of event, adding in a parameterless constructor and then calling it.

Pretty quick. My own test case passed, so I had a strong indication that it was fixed, but I knew if I submitted it without an automated test it would probably get rejected. The problem is that I had no idea how to build the automated tests or where to put them.

I had a quick scan through LayoutTests, and in the “fast” directory there is an “events” directory which seemed liked the logical place to start. I followed the examples of other tests, I created a simple test and an “expected” results file and then gave the test runner a go. Boom! it failed. It took a little bit of looking, I found that the results of the test run were stored in “/tmp/layout-test-results/results.html” and it gives you a visual diff of the actual output vs the expected – it was a single new line character that was causing the problem.

That was me done. I created the ChangeLog and attached it to the bug, set r to ? (this was an oddity that I had to learn about). After the first review there were a couple of changes I needed to make. The second review indicated that I updated the wrong ChangeLog and some other smallish issues. But after that it was ok and submitted.

And here it is: http://trac.webkit.org/changeset/88187, it is not a complex fix but it is one I am proud of, if all the ports include the fix then my code will be used by the eleventy billion users of WebKit (ok – I have no idea of the number of users, but I know it is very large number) and now I can get on with fixing my LeviRoutes framework ;)

In my eyes, this is one of the powers of Open Source. Rather than just report a bug and hope someone picks it up, and then wait for the next major release of the software to see if it is fixed, I have the power to go in and fix the problem, and if it stands up to muster I can get the solution published.

Beautiful!

Permalink | Leave a comment  »

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.”, which you can logically assume to be only on a forward, backwards navigation, not a replaceState or pushState.

This might sound odd. There is no mechanism to detect change in url afterit changes. You get notification via onpopstate when the user navigates forwards or backwards through your application, but not actually when it changes. This is apposed to onhashchange which does fire when the document fragment changes.

This causes us problems.

LeviRoutes listens to changes in your URL, it allows you to build applications that are responsive to the current URL, and are decoupled from navigation. So rather than have your code littered with “if(url == ”/“) { doA(); } if (url == ”/categories") { doB(); } you can now specify:

var app = routes();
app.get("/", doA);
app.get("/categories", doB);

Simple right?

It would be excellent if it was that simple, but it is not. We don’t know when the URL changes via pushState. This forces us o bind our logic in our controller to call the same code that LeviRoutes would call when it detects a change in URL via normal navigation.

Now I have to bastardise my code:

var app = routes();
app.get("/", doA);
app.get("/categories", doB);

.....
function gotoA () {
    history.pushState({}, "A", /);
    doA();
}
...

Pretty messy right?

I would love to see an event “onstatechanged” (or perhaps, onpushstate and onreplacestate) triggered when the user pushes or replaces state on to the history object so that I can capture the code and return to my simple routing logic.

var app = routes();
app.get("/", doA);
app.get("/categories", doB);

function gotoA () {
    history.pushState({}, "A", /);
}

I am not the only person asking for this: http://www.google.com/search?q=onpushstate

So, how am I going to solve this problem? I am going to wrap the History API and proxy pushState to call the natural pushState and also fire a new custom event. Hmph :\

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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? Well the answer is simple, I posted it on twitter, and then forgot to post this blog – DOH!

It is an interesting project because it does a couple of cool things that make it super easy for you to use.

• All you need is your Web Store URL – for example see http://badgemator.appspot.com/#https://chrome.google.com/webstore/detail/dhbgookgdfbbinnmmkbmjgolhikbbhpj to get started.
• It is self contained – it base64 encodes your initial logo and css so that all you need to do is drop a single script tag into your HTML and BOOM, you have a great looking badge with no extra HTTP requests. Check out the source of Appmator and you will see there is a simple html tag that points to an embedded script.
• It will only appear for Chrome users.
• If installed on your app, it will detect if your app is installed using the window.chrome.app.isInstalled variable and not show it to users who already have your app running.
• It will scan your listing page and pluck out all the important information including your Logo
• The default style is “basic” to say the least, but you can style this up to look however ever you want, it could look like the Butter bar, or it could be some crazy 3d transform.

My good friend Mike Mahemoff suggested a neat use of URL fragments a while ago to enable quick sharing of links, hence you will see all my services support #URL at the end, so that if you wanted you could share it on Twitter and any reader would see the completed action – most of my service logic is on the client side.

I really need some more designs for default badges, so feel free to fork this project and make some changes to the CSS and I will incorporate it into the project and give you credit and links from the app.

Permalink | Leave a comment  »

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. I wanted a framework that would: * execute specific methods when the URL changed and matched a certain pattern; * is quick and easy to use; * listened for changes in the URL fragment; * worked with HTML5 History APIs; * worked on browsers that don’t support any of these features; * and most importantly doesn’t try to do anything else.

Thus LeviRoutes was born. It came about because I am working on a project that uses NodeJS with the Express framework, and the URL handling is very simple to access and I wanted to replicate this behavior in the browser, not just the server. My ultimate goal is for me to be able to share a lot of the logic that is on the server with the client and thus cut down the amount of code that I need to do.

The LeviRoutes project started with juat the ability to listen to changes in the HTML5 History by listening to the “onpopstate” event. When there is a “pop”, the matching code is invoked with the current window.location object. It later included a onhashchange event listener to listen to changes in the fragment and finally included a listener for the onload event. By listening to these three events.

Lets have a look at the simplest app that we can build with this.

var app = new routes();
app.get("/", function(req) { alert("On /"); });

Pretty simple right! Under the hood, the system is listening for when the URL is just “/” and nothing more, if your URL was “/index.html” the code would not be executed. If you wanted to watch for when the URL is “/index.html” you would need a route with that as the exact string.

Looking for just the root directory by itself is not very interesting, and neither are simple static URL’s. Thus the named parameters from Rails and other frameworks is built straight in, and this is the most interesting part.

It also supports named parameters for route syntax:

!#javascript
app.get("/:category", function(req) { alert("In " + req.params.category); });
app.get("/:category.:format", function(req) { alert("format: " + req.params.format); });

This is simple, yet powerful, LeviRoutes allows you to treat the URL as an input event to your controller, or as the controller.

Have a play, let me know what you think, and look out for my next post about FormFactorJS.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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

Web-apps hosted on the open web have not had this ability, until now.

Chrome has recently brought this idea to the web with some added powers. Mainly:

• Your web app can still run even when your app is closed,
• Your web app can still run when the browser is closed,
• Your web app can run after system start-up.

This is very powerful.

Actually let me re-phrase that. This is amazingly, unbelievably, stonkingly powerful. [definition: stonking]

So, how do you use them?

The good thing is it is really simple – a matter of two steps.

Step 1, this is currently only available to apps – not web sites. Apps in Chrome are defined using a manifest file. You as the developer must include a permission “background” to enable this feature. More on the permissions model can be found on code.google.com.

{
  "name" : "test",
  "version" : "0.0.0.1",
  "permissions" : ["background"],
  "app" : {
    "launch" : {
      "urls" : ["http://appmator.appspot.com/"],
      "web_url" : "http://appmator.appspot.com/"
    }
  }
}

Step 2, a little bit of Javascript magic…. actually, it is not magic, it is a simple call to window.open().

win = window.open("background.html#", "background", "background");

The detail is in the 3rd parameter which is reserved for specs. When Chrome is running with the “background” permission it will launch this page with no visible surface and track it in perpetuity.

By using window.open, it means that users and developers can toggle the state of the background running task by simply calling window.close, which will cause it to stop running. This also means that requesting window.open without a url, but with the background name will return a reference to the running window that can then be closed.

You can only open a url that is specified in the domain of the “urls” extents in the manifest – so for example you couldn’t open a background page to google.com if you didn’t verify you own that domain.

Now your app can run in the background. It will start up when the user logs into their machine, it will still be running when the user closes the visible browser (if you completely kill

POP QUIZ: How can my background page talk to my app pages?

…

…

…

ANSWER: SharedWorkers my hairy friend. Don’t use references to windows, that is so 2005.

In other exciting news, Appmator has been modified to support the “background” permission.

Permalink | Leave a comment  »