At one point he showed off the WebKit support for <input speech> implementation that allows you to talk into an input area. You click on the microphone, speak in, and it will get translated for you with the results. I am not sure if you can tweak how the translation is done (choose a Nuance vs. Google vs. …. solution for example), but it definitely works well out of the box.

I was surprised to see this already landed in my developer-channel Chrome, so I was incented to do something with it on the plane trip back from Berlin to New York City. Something simple would be to give the user the ability to enable speech on any input. I whipped up a Chrome extension using the context menu API, but was quickly surprised to see that there isn’t support in the API to get the DOM node that you are working on. Huh. Kinda crazy in fact.

Then the whizzkid antimatter came to the rescue with his cheeky little hack around the system. Here is how it plays out in the world of this extension:

The background page

First we enable the context menu on any “editable” element (vs. anywhere on the page, on any text, etc), and when clicked we fire off an event to the content script in the given tab:

<script>
chrome.contextMenus.create({
    title: "Turn on speech input",
    contexts: ["editable"],
    onclick: function(info, tab) {
        chrome.tabs.sendRequest(tab.id, 'letmespeak')
    }
});
</script>

Catching in a content script

A content script then does two things:

• Listens for mousedown events to keep resetting the last element in focus
• Catches the event, and turns on the speech attribute on the target DOM node

var last_target = null;
document.addEventListener('mousedown', function(event) {
    last_target = event.target;
}, true);
 
chrome.extension.onRequest.addListener(function(event) {
    last_target.setAttribute("speech", "on");
    last_target = null;
})

Wire-y wire-y

Of course, it all gets wired up in the manifest:

{
    "name": "Turn on Speech Input",
    "description": "Turns on the speech attribute, allows you to speak into an input",
    "version": "0.1",
    "permissions": ["contextMenus"],
    "minimum_chrome_version": "6",
    "background_page": "background.html",
    "content_scripts": [{
        "matches": ["<all_urls>"],
        "js": ["input-speech.js"]
    }]
}

This trivial extension is of course on GitHub (I want git-achivements after all! :).

A couple of things trouble me though:

• The microphone icon should sit on the right of the input, however when dynamically tweaked like this it shows up on the left by mistake [BUG]
• I have also played with extensions such as Google Scribe. Adding icons like this doesn’t scale. Having them show up all the time gets in my way. I think I want one ability to popup special powers like scribe completion, or speech-to-text, without it getting in my way
• When services are built into standard elements like this, it feels like I want to have the ability to tweak how they work (with great defaults of course, as 99.9999% of the time they won’t be changed.

You?

I realized that I hadn’t written a Chrome extension, so I wanted to try it on for size. I thus created an incredibly simple extension that tells you the size of the window on the fly: Chrome Win Size.

In an ideal world this extension would be as easy as:

• Create a bit of HTML for the tooltip
• Attach an onresize handler to the window that changes the HTML

Unfortunately, it wasn’t quite that easy…. but it was pretty close. The only difference involves the fact that you can’t easily get the window object to resize.

Here is the entire extension to show how simple it is:

Web page for the tool strip

For now, I wanted to put the windows size information in the toolstrip. This isn’t ideal, especially if you don’t have other extensions that turn on the toolstrip. It could be nicer to either: have a subtle grey width/height in the background of the URL bar itself; show the info only when a certain keystroke is pressed. That is all for version 0.2 :)

As you will see below, the extension is just a Web page, and the toolstrip is just a div. You could use class="toolstrip-button" but for now a click doesn’t do anything, so I didn’t use that. Instead I have a title attribute that uses plain English to explain the info.

Once you have the HTML itself, you also have some JavaScript to do the work. The init kicks things off the first time, but the interesting code is the chrome.extension.onConnect.addListener piece that sets up the extension so that a content script can talk to it via postMessage.

<html>
<head>
<script>
 
// Query the current window (anyone will do) and set the window size in the toolstrip
function showDimensions() {
    chrome.windows.getCurrent(function(w) {
        var el = document.getElementById("windowsize");
    	el.innerHTML = w.width + " x " + w.height;
    	el.setAttribute("title", "width: " + w.width + "px, height: " + w.height + "px");
    });
}
 
// Listen to the content script and when told there is a change, query again
chrome.extension.onConnect.addListener(function(port, name) {    
  console.assert(name == "resize");
  port.onMessage.addListener(function() {
      showDimensions();
  });
});
 
</script>
</head>
<body onload="showDimensions()">
  <div id="windowsize"></div>
</body>
</html>

Content Script

Why do we need a content script? Ideally, we would be able to grab a window in the extension and add a resize listener to it and be done. That isn’t the case right now though. In the code above, the window object that we get in w from chrome.windows.getCurrent(function(w) {... isn’t a DOM Window, but just something with a few properties (width, height, etc).

To get an actual DOM window, we need to inject a content script and have that talk to the extension. The code is as simple as below… which does the postMessage() back to the listener that we setup in the extension:

// When the window resizes send a quick message to the extension
window.addEventListener("resize", function() {
	chrome.extension.connect({name: "resize"}).postMessage();
}, false);

Manifest

Now we need to put it all together and that is where the manifest comes in. It is here that we tell Chrome where the files are for the toolstrip and content script, and what permissions they have (e.g. give it the tabs permission), as well as metadata:

{
  "name": "Window Size", 
  "version": "0.1",
  "description": "Displays the size of the main window",
/*  "icons": { "128": "gmail-128x128.png" }, */
  "permissions": [
    "tabs"
  ],
  "toolstrips": [
    "winsize.html"
  ],
  "content_scripts": [
    {
      "matches": ["http://*/*", "https://*/*"],
      "js": ["contentscript.js"]
    }
  ]
}

Caveats

Even with the content script hack, it is pretty easy to do this kind of thing. It would be nice to do more with the window object as the hack has limitations beyond the extra code. For one, if you are on a page such as chrome://extensions/ nothing kicks in (due to the matching). Rather than matching on pages for content scripts to embed, it would be much better to declare that you care about windows themselves.

The toolstrips themselves are a little bulky and ugly, at least on Chrome for Mac (which is very much in beta) and as mentioned earlier…. unless you are using a bunch of extensions, it feels very unChrome-like to use that space.

FYI: To package an extension on Mac/Linux use this handy script as the built-in functionality isn’t there yet.

All in all a decent experience already. Really nice to just work on an HTML document to kick out the functionality. The idealist in me would love to see Jetpack and Chrome Extensions coming together so Web devs had One Way to extend the platform…… The Web is in a fortunate position to have folks like Aaron Boodman, Aza Raskin, Atul Varma and many others on the case of Web extensions.