tl;dr: Load the component in an iframe, then reload()

Backstory

Steve Souders and I were chatting last week about his blog post and he was expressing his disappointment with the status quo of the short expiration time of those omnipresent third party scripts like the Facebook SDK (which loads Like button among others). We need short expiration on those because we need to be able to push quick fixes to critical bugs. And we cannot ask webmasters to keep up with versioned file names.

So the question is how do you set far-future Expires header of a static URL (like http://connect.facebook.net/en_US/all.js) and at the same time be able to update the content of this file without changing its filename.

Ahaa!

Today I had this sudden moment of clarity that we can use location.reload() of an iframe that contains the resource in question.

reload(true) forces uncoditional GETs.
reload(false) (default) sends coditional GETs.

So I can load the component in an iframe and then reload() the iframe. Cross-origin restrictions kick in when the static resource is on a CDN domain. This can be solved by loading an HTML page in an iframe and reloading it. All resources referred to by this page will be revalidated with a conditional GET.

Codeh

Far-future expiring component with a static URL:

<img src="http://stevesouders.com/images/book-84x110.jpg">

Version-checking iframe:

<iframe id="i" src="about:blank"></iframe>

Test-links:

<p><a href="javascript:loadit()">load image in iframe</a>
<p><a href="javascript:reloadit()">reload the image in the iframe</a>

And the JS code:

// load the version-checking html
function loadit() {
  document.getElementById('i').src = 'versioncheck.html';
}

// reload iframe
function reloadit() {
  window.frames[0].location.reload(false);
}

This is it. Here's the test page.

The versioncheck.html does nothing but include the static resource. Here it is.

Results

Safari, IE9, FF, Chrome are all consistent - when you reload() the versioncheck.html, conditional GETs go out to the HTML and all the resources in it. Then the server can reply 304 if the static resource hasn't changed. Or send a new file if the contents has changed.

Not entirely trusting the browser tools, also validated the 200 and 304 responses tailing the access log file on the server.

Conclusion

Plus: you can update the content of static URL with far-future Expires fairly easily.

Minus:
1. Additional 304s. Two if CDN domain is different than the page, 1 otherwise.
2. The users sees the updated resource on the next page view, sorta like App Cache

So for those omnipresent third party JavaScripts... They currently have short expiration times - between 20 mins and 2 hours. In that time if the user needs the script again, no requests go out.

But if you use the technique outlined, you can set their Expires header to 10 years in the future and for every single page view make two more conditional requests with likely a 304 Not Modified response. These extra requests, of course will not interfere with the user experience, because they will be lazy.

So you get faster user experience with more HTTP requests and delayed-till-next-page-view update.

So I tweaked the test ever so slightly to print out timing info in the document.title and after the page is done.

The test is essentially how does a slow print stylesheet affect the rendering of the page on the screen.

<link rel="stylesheet" href="screen.css" media="screen">
<link rel="stylesheet" href="print.css"  media="print">

In the experiment I have screen.css delayed with 5 seconds and print.css delayed 10 seconds.

Results 5 years ago

Browsers blocked rendering waiting for print.css. Some took 10 seconds (downloading print.css and screen.css in parallel), some took 15. Why, oh why? It's a print CSS, you don't need this sh...eet.

Results today

Good guy Opera, doesn't even wait for screen.css. After some timeout, O renders unstyled page and restyles after screen.css arrives. Yes, brave O takes rendering risks this way, all others wait for the screeen.css before styling anything. Still, onload fires in ~10s, so this is bad. All your onload JS code is blocked on a useless print.css

FF blocks rendering on the print.css. Boo! Nothing renders for 10 seconds. And it fires onload after ~10s. Boo-boo! At least it loads both stylesheets in parallel. Galaxy (Android) waits for print.css too. How often do you print from a mobile device? Same in IE8 and IE9. Even more retarded in IE is DOMContentLoaded event also waiting for 10 seconds. speech=less.

Safari, Chrome, Mobile Safari - render after 5 seconds, meaning only after screen.css. There is hope for the humanity. However the onload fires in 15 seconds. So the two CSS files are downloaded sequentially. Kinda makes sense, print.css is low priority and should give way to everything else. Still could start earlier if there are no other downloads competing for precious resources.

So on the wall of shame - IE worst, FF yuck, Webkit bad, O least bad.

Recommendation

Ditch media="print" if you have one! (Hey why isn't this a yslow/pagespeed rule?). Ditch it because in the best case scenario it will only block onload. In the worst case it will block initial paint, onload and DOMContentLoaded. Sitting in front of a white page with no feedback is the worst possible user experience.

Put all (should be minimal anyway) print rules inline in your normal screen stylesheet.

@media print {
  body {font: fit-to-print}
  .big-ads, .sidebar, .menu {display: none}
}

What's a webmaster to do? All I need is a simple PLAY button next to each link

While I was aware of SoundManager, I accidentally stumbled across sound.js yesterday and thought I should give it a chance. Tiny (3K), it should give me an easy way to do x-browser playing with the help of some SWF for IE, I assume. Dropped the JS from their CDN (nice), but then what? "Online documentation" points to API docs which I don't feel like reading. Demos don't give you the code. Next.

Sound manager has a nice "basic template". Awesome. Replace the sound.js js with SoundManager's. Load in FF. It's looking for an swf. In FF. Why? Because FF doesn't play mp3. Well, I'd rather convert the MP3 than have the user load SWF. But anyway, I drop the swf. For whatever reason (like you need a reason!) I've disabled flash in FF and forgot about it. So no sound in FF. And maybe I'm not the one. Requiring SWF in FF feels unnecessary, although I'm sure Sound Manager probably has way around it. I'm sure. I've met the author, he's brilliant. But... I still need to write some JS to initialize the playing. And if I'm to write code, might as well go solo.

Here's what I came up with, hope it helps.

Disclaimer: I haven't tested in IE, and I mean at all. Should probably work in newer IEs

Demo

http://anacondalimousine.com

Codez, how they work

Everything in an immediate function. Unobtrusive. Bail if (IE) browser doesn't know about Audio.

(function () {
  if (!Audio) return;

  // ...

}());

Codes for play and stop:

var playsym = "▶", stopsym = "■";

Some browsers play mp3, some OGG, so let's just change the extension and have both .mp3 and .ogg on the server

var extension = new Audio().canPlayType('audio/mpeg') === '' ? 'ogg' : 'mp3';

Loop though all links on the page, find the ones that point to .mp3

var dl = document.links;
for (var i = 0; i < dl.length; i++) {
  if (dl[i].href.split('.').slice(-1)[0] !== "mp3") {
    continue;
  }
  var p = document.createElement('button');
  p.innerHTML = playsym;
  p.onclick = play;
  dl[i].parentNode.insertBefore(p, dl[i]);
}

Forgot to mention, my markup is as simple as it gets:

  <p><a href="virus.mp3">Virus</a></p>
  <p><a href="yesterday.mp3">Yesterday</a></p>
  <p><a href="parting.mp3">Parting</a></p>
  <p><a href="faultline.mp3">Faultline</a></p>

So all I'm doing is insert a PLAY button right before the link. Onclick it should play.

The play() function initializes Audio with the appropriate extension, based on what the browser supports:

  function play(e) {
    var button = e ? e.target : window.event.srcElement;
    button.innerHTML = stopsym;
    var a = new Audio(button.nextSibling.href.replace('mp3', extension));
    a.play();

And if you click the same button as the music plays, you stop it and reset the button click handler:

    button.onclick = function() {
      a.pause();
      button.innerHTML = playsym;
      button.onclick = play;
    };
  }

That's it

So simple and tiny, it's all inline, no extra requests, not a SWF in sight. Support for 72.3% of all browsers. The other 30% can still download the file and play it with a separate program.

SoundManager and, I assume, sound.js have more features, events and other shiny, but for my simple purpose I'm so happy with the result I'll even blog about it

For full source - view source at http://anacondalimousine.com

Moarr info:

• Article on Opera.com
• MDN

p.s. about the mp3 to ogg conversion... ffmpeg ftw:

$ ffmpeg -i in.mp3 -acodec vorbis -aq 60 -strict experimental out.ogg

jsdrama.com is live though. Enjoy and feel free to add more next time.

(image from wikipedia)

Here's a cover of We Wish You a Merry Christmas I just did. It's in a Bulgarian (and other Balkan countries) style in 7/8 tempo (and 9/8th at one place). This is me channeling my inner Goran Bregovich

We Wish You a Merry Christmas (7/8th and 9/8th)

Continuing the tradition (why did I skip last year?! oh I know, because 7/8 is damn confusing and I failed last year), here are the others:

• Feliz Navidad 2009
• Jingle Bells 2008

It's amazing to look back over the years and see how little I have grown as a musician and recording technician

Imagine there's no quirksmode
It's easy if IE6 dies
No Trident below us
And all the data URIs

Imagine all the web devs coding for today

You may say I'm a dreamer
But I'm not the only one
I hope some day you will upgrade
And the world will browse as one

The web performance and operations conference, Velocity Europe, is just around the corner. This always sold-out event is making its EU debut this year in Berlin.

Get your ticket now (with 20% discount no less) or punish your users and clients with slow user experiences

Info:

• url: http://velocityconf.com/velocityeu/
• cost: €600 after 20% discount (ow €749)
• discount code: veu11sts
• when: Nov 8-9
• where: Berlin
• hashtag: #VelocityConf

Some highlights from the program:

• Jon Jenkins will be talking about Amazon Silk.
• Browser sessions from Chrome, Firefox, and Opera.
• David Mandelin talking on JavaScript engines.
• Jeff Veen talking about Designing for Disaster.
• Estelle Weyl on Mobile UI Performance.

Full list of speakers here

Full disclosure: I'm in the program committee for the US event

Task: get me a 16x16 favicon for yahoo when all you have is the Yahoo search page

1. goto yahoo search, right click the icon, Inspect
   
2. Download the sprite:

   $ curl http://a.l.yimg.com/pv/i/us/sch/gr5/metro_sprite_20110907.png > ys.png
   

   here it is:
   

3. While inspecting the CSS you noticed

   width: 16px;
   height: 12px;
   background-position: -117px -95px;
   

   This helps us cut precisely as opposed to guess the coordinates

4. Crop it:

   $ convert ys.png -crop 16x12+117+95 yfavicon.png
   

   The result is a 16x12 image:
   

5. And because we have this arbitrary requirement that we want all favicons to be 16x16 because our design says so, let's resize it to fit a 16x16 box and center it inside the box

   $ convert yfavicon.png -background transparent -gravity center -extent 16x16 y.png
   

   Here:
   

6. And just because, let's make it 160x160 with colored background to make sure the command works

   $ convert yfavicon.png -background orange -gravity center -extent 160x160 yorange.png
   

   

7. Enjoy the rest of your day having saved some time by doing things on the command line instead of dealing with UI that gets in the way

Facebook now offers a new asynchronous snippet to load the JavaScript SDK, which lets you load social plugins (e.g. Like button) among doing other more powerful things.

It has always been possible to load the JS SDK asynchronously but since recently it's the default. The code looks pretty damn nice (I know, right!), here's how it looks like (taken from here):

(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) {return;}
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));

Some nice steal-me JS patterns here:

• immediate (self-invoking) function so not to bleed vars into global namespace
• pass oft-used objects (document) and strings ("script", "facebook-jssdk") to the immediate function. Sort of rudimentary manual minification, while keeping the code readable
• append script node by using the first available script element. That's 99.99% guaranteed to work unless all your code is in body onload="..." or img onload or something similar (insanity, I know, but let's allow generous 0.01% for it)
• assign an ID to the node you append so you don't append it twice by mistake (e.g. like button in the header, footer and article)

All buttons' JS files

Other buttons exist, most notably the Twitter and Google+1 buttons. Both of these can be loaded with async JavaScript whether or not this is the default in their respective configurators.

So why not make them all get along and shelter them under the same facebook immediate function? We'll save some bytes and extra script tags in the HTML. For G+/T buttons all we need is a new script node. Google+'s snippet has some additional attribs such as type and async, but these are not really needed. Because type is always text/javascript and async is always true. Plus we kinda take care of the async part anyways.

The end result:

  <div id="fb-root"></div>
  <script>(function(d, s, id) {
    // fb + common
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) {return;}
    js = d.createElement(s); js.id = id;
    js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
    fjs.parentNode.insertBefore(js, fjs);
    // +1
    js = d.createElement(s);
    js.src = 'https://apis.google.com/js/plusone.js';
    fjs.parentNode.insertBefore(js, fjs);
    // tweet
    js = d.createElement(s);
    js.src = '//platform.twitter.com/widgets.js';
    fjs.parentNode.insertBefore(js, fjs);
  }(document, 'script', 'facebook-jssdk'));</script>

So this thing loads all three JS files required by the three buttons/plugins.

Additionally we can wrap the node creation/appending part into a function. So all the code is tighter. Here's the final snippet:

<div id="fb-root"></div><!-- fb needs this -->
<script>(function(d, s) {
  var js, fjs = d.getElementsByTagName(s)[0], load = function(url, id) {
    if (d.getElementById(id)) {return;}
    js = d.createElement(s); js.src = url; js.id = id;
    fjs.parentNode.insertBefore(js, fjs);
  };
  load('//connect.facebook.net/en_US/all.js#xfbml=1', 'fbjssdk');
  load('https://apis.google.com/js/plusone.js', 'gplus1js');
  load('//platform.twitter.com/widgets.js', 'tweetjs');
}(document, 'script'));</script>

All buttons' markup

Next is actually advising the scripts where the widgets should be rendered. Facebook offers XFBML syntax, with tags such as <fb:like>, but it also offers pure HTML(5) with data-* attributes. Luckily, so do all others.

Here's an example:

<!-- facebook like -->
<div class="fb-like" data-send="false" data-width="280"></div>
<!-- twitter -->
<a class="twitter-share-button" data-count="horizontal">Tweet</a>
<!-- g+ -->
<div class="g-plusone" data-size="medium"></div>

G+ requires a div element (with g-plusone class name), Twitter requires an a (with a twitter-share-button class name). Facebook will take any element you like with a fb-like class name (or fb-comments or fb-recommendations or any other social plugin you may need)

Also very important to note that you can (and should) load the JS files once and then render as many different buttons as you need. In Facebook's case these can be any type of plugin, not just like buttons. Economy of scale - on JS file, many plugins.

All together now

So here's the overall strategy for loading all those buttons.

1. Copy the JS above at the bottom of the page right before /body just to be safe (G+ failed to load when the markup is after the JS). This will also help you make sure there should be only one place to load the JS files, although the snippet takes cares of dedupe-ing.
2. sprinkle plugins and buttons any way you like anywhere on your pages using the appropriate configurator to help you deal with the data-* attributes (FB, G+, Tw)
3. Enjoy all the social traffic you deserve!

To see it all in action - go to my abandoned phonydev.com blog. Yep, those buttons play nice in mobile too.

You get an input:

<input>

You add an x-webkit-speech attribute

<input x-webkit-speech>

And voila!

Or if you don't have a recent Chrome version, here's what these who have a recent Chrome version see:

Nice.

Textareas

Speech inputs - gotta love them. But in textareas - you can't have them. So you can put an input and a textarea and copy over the content.

html:

<textarea id="txt"></textarea>
<input x-webkit-speech id="mike"/>

With some CSS you can remove the border, add pointy cursor, etc make it look like not an input.

#mike {
    font-size: 25px;
    width: 25px;
    height: 25px;
    cursor:pointer;
    border: none;
    position: absolute;
    margin-left: 5px;
    outline: none;
    background: transparent;
}
#txt {
    height: 150px;
    width: 150px;
}

Finally a little JavaScript to a/ unfocus the input and b/ carry over the content from the input to the textarea

var mike = document.getElementById('mike');
mike.onfocus = mike.blur;
mike.onwebkitspeechchange = function(e) {
    //console.log(e); // SpeechInputEvent
    document.getElementById('txt').value = mike.value;
};

That's all there is. Click over to the demo.

Here's what you should see in Chrome:

You can see that console.log() there - it's definitelly worth exploring. The thing is a SpeechInputEvent type of object is passed to the handler of the onwebkitspeechchange event. This object has some interesting properties, such as the array results[] which is number of guesses what you've said and confidence (0 to 1 it seems) in the guess.

Enjoy and go ahead and add these all over the place!