Protocol-Relative URLs

One of the things I love about programming and development in general is that, no matter how well you think you know something, there's always something that can surprise you.

It doesn't matter what language/domain/stack/toolset you're working with, there are often ways of doing things you haven't thought of.  Sometimes these other ways of doing things are obscure or different to your normal way of thinking.  That's why you've missed them to begin with.

Other times, can't see why you haven't thought of them.  I like it when the surprises are so simple, so immediately effective, that you can be pretty sure you'll remember them from then on.

So to the point.

I'm currently reading Javascript Web Applications.  An excellent book by Alex MacCaw, the author of Spine.  Aside from the book being pretty well written, there are some awesome nuggets of information in there.  In a section discussing the benefits of using a CDN, the following example code is used:
<script src="//"></script>
Just double check that again, did you see it? There's no protocol declared for the script request. This makes it a protocol-relative URL.  The request for the script will be completed over the same protocol as the current page.

Relative URLs? Got that.  Protocol-relative URLs? Why haven't I thought of that before!?

The advantage of this is that you can prevent virtually all annoying mixed content warnings!  Paul Irish has some more info and highlights one or two quirks with IE (of course) and stylesheets.  But the trick can be used for any extra content to load into the page.  It can also be used in pretty much every browser.  IE 3.0 supported it, why didn't I learn this in Web Dev 101?

A Simple LocalStorage Model

I've been playing around with Google Chrome extensions again (you should too, they are really simple).

Chrome extensions at their most basic level consist of HTML and Javascript; allowing full utilisation of HTML5 APIs such as WebStorage, IndexedDb and everything else. Chrome sandboxes extensions just as it does with each tab you have open, so an extension follows the HTML5 requirements of only having access to it's own 'domain' of data.

When creating an extension, you'll likely want to store some data. The HTML5 WebStorage spec allows a site (or extension in this case) to store simple key value pairs. This is ideal for extensions looking to keep track of simple things such as user preferences. It shouldn't be used for complex data or data that you'll be expecting to search over. Use IndexedDb for that.

The following is a simple mechanism which can be used in an extension to store and retrieve data using localStorage. It provides no data validation or verification other than returning null if no data is found and storing values as JSON.

Stored properties are added by calling the settings.implement function. The function will take any number of parameters, so additional properties can be added with ease. Properties are checked to see if they already exist before being created.

As the model is in Javascript, it can of course be utilised by any web page as well :-)