Frost went down the route of physical devices, what you should test and their breakdown in prices. This post will be a list of services I have come across for testing on a vast array mobile devices without having to purchase said devices.

DeviceAnywhere

DeviceAnywhere Test Center is a device lab chock full of common and not so common devices that you can access remotely though their application. It gives you remote access to real devices, not emulators, and the ability to do almost anything to them. In my case I would only access the browser apps on each phone but you have full access to the phone and its capabilities.

Pros:

• Record video and image capture
• Invite other users to a watch or participate in testing
• Huge amount of devices including tablets.
• Good support for emulating touch and gestures.
• Relatively cheap.

Cons:

• Laggy and not super responsive (Latency from Australia most likely faster in USA and UK).
• Automation and scripting is part of their enterprise product which is very pricey.

Price: ~$16USD/hr for general access to the device lab. Packages and bulk hours equals cheaper prices.

Perfecto Mobile

PerfectoMobile MobileCloud is very similar to DeviceAnywhere both offer a huge array of real devices you can remotely access. PerfectoMobile uses a flash based web app for accessing and testing on devices.

Pros:

• Record video and image capture
• Invite other users to a watch or participate in testing
• Huge amount of devices including tablets.
• Have dedicated handset options: Blackberry and Nokia

Cons:

• Laggy and not super responsive (Latency from Australia most likely faster in USA and UK).
• Automation and scripting is part of their enterprise product which is very pricey.
• Touch and gestures aren’t that easy to accomplish.
• Pricey, even for entry level access.

Price: ~$170USD/10hrs per month. Blackberry $4USD/hr, Nokia $14USD/hr.

BrowserStack

BrowserStack recently launched remote access to an array of Mobile and tablet emulators with real device configurations. All in browser access.

Pros:

• Good cheap pricing
• Can test localhost remotely¹
• Automation! BrowserStack has an API for spinning up an emulator and scripting interaction. Huge.

Cons:

• Not real devices, but when it’s for browser testing that’s less of an issue.
• Smaller, but growing, list of mobile browsers. But really they cover 99% of the most used ones already.

Price: $19USD/Month for an individual. Gives you access to Mobile and desktop browsers.

¹ Note: BrowserStack provides their own implementation of a localtunnel like service. You can of course use localtunnel or similar on your own machine for testing your localhost with other services.

Nokia Remote Device Access

Nokia RDA is a device lab of, you guessed it, Nokia devices where you can remotely access an array of Nokia phones.

Pros:

• It’s free! You just need to sign up for Nokia dev account.
• Huge list of Nokia phones available.
• Record and screen capture.
• Pretty responsive.

Cons:

• Pretty lame con but it’s free and therefore could disappear.

Price: FREE!

So that’s it. If you know of any other services that I may have missed let me know. I think a combination of real devices and remote access is the killer setup for any mobile development shop or individual.

Short URL: http://cssn.in/ja/040

Basically it’s a way to map a combined/minified file back to an unbuilt state. When you build for production, along with minifying and combining your JavaScript files, you generate a source map which holds information about your original files. When you query a certain line and column number in your generated JavaScript you can do a lookup in the source map which returns the original location. Developer tools (currently WebKit nightly builds, or Google Chrome Canary) can parse the source map automatically and make it appear as though you’re running unminified and uncombined files. As of writing Firefox has a blocked status for Source Map support. See MozillaWiki Source Map entry for more details.

The above demo allows you to right click anywhere in the textarea containing the generated source. Select “Get original location” will query the source map by passing in the generated line and column number, and return the position in the original code. Make sure your console is open so you can see the output.

Real world

Before you view the following real world implementation of Source Maps make sure you’ve enabled the source maps feature in either Chrome Canary or WebKit nightly by clicking the settings cog in the dev tools panel and checking the “Enable source maps” option. See screenshot below.

So… That Source Map query demo is cool and all but what about a real world use case? Take a look at the special build of font dragr at dev.fontdragr.com in Chrome Canary or WebKit nightly, with source mapping enabled, and you’ll notice that the JavaScript isn’t compiled and you can see all the individual JavaScript files it references. This is using source mapping, but behind the scenes actually running the compiled code. Any errors, logs and breakpoints will map to the dev code for awesome debugging! So in effect it gives you the illusion that you’re running a dev site in production.

Why should I care about source maps?

Right now source mapping is only working between uncompressed/combined JavaScript to compressed/uncombined JavaScript, but the future is looking bright with talks of compiled-to-JavaScript languages such as CoffeeScript and even the possibility of adding support for CSS preprocessors like SASS or LESS.

In the future we could easily use almost any language as though it were supported natively in the browser with source maps:

• CoffeeScript
• ECMAScript 6 and beyond
• SASS/LESS and others
• Pretty much any language that compiles to JavaScript

Take a look at this screencast of CoffeeScript being debugged in an experimental build of the Firefox console:

The Google Web Toolkit (GWT) has recently added support for Source Maps and Ray Cromwell of the GWT team did an awesome screencast showing source map support in action.

Another example I’ve put together uses Google’s Traceur library which allows you to write ES6 (ECMAScript 6 or Next) and compile it to ES3 compatible code. The Traceur compiler also generates a source map. Take a look at this demo of ES6 traits and classes being used like they’re supported natively in the browser, thanks to the source map. The textarea in the demo also allows you to write ES6 which will be compiled on the fly and generate a source map plus the equivalent ES3 code.

How does the source map work?

The only JavaScript compiler/minifier that has support, at the moment, for source map generation is the Closure compiler. (I’ll explain how to use it later.) Once you’ve combined and minified your JavaScript, alongside it will exist a sourcemap file. Currently, the Closure compiler doesn’t add the special comment at the end that is required to signify to WebKit and Chrome Canary dev tools that a source map is available:

//@ sourceMappingURL=/path/to/file.js.map

This enables developer tools to map calls back to their location in original source files. If you don’t like the idea of the weird comment you can alternatively set a special header on your compiled JavaScript file:

X-SourceMap: /path/to/file.js.map

Like the comment this will tell your source map consumer where to look for the source map associated with a JavaScript file. This header also gets around the issue of referencing source maps in languages that don’t support single-line comments.

The source map file will only be downloaded if you have source maps enabled and your dev tools open. You’ll also need to upload your original files so the dev tools can reference and display them when necessary.

How do I generate a source map?

Like I mentioned above you’ll need to use the Closure compiler to minify, concat and generate a source map for your JavaScript files. The command is as follows:

java -jar compiler.jar \ 
     --js script.js \
     --create_source_map ./script-min.js.map \
     --source_map_format=V3 \
     --js_output_file script-min.js

The two important command flags are --create_source_map and --source_map_format. This is required as the default version is V2 and we only want to work with V3.

The anatomy of a source map

In order to better understand a source map we’ll take a small example of a source map file that would be generated by the Closure compiler and dive into more detail on how the “mappings” section works. The following example is a slight variation from the V3 spec example.

{
    version : 3,
    file: "out.js",
    sourceRoot : "",
    sources: ["foo.js", "bar.js"],
    names: ["src", "maps", "are", "fun"],
    mappings: "AAgBC,SAAQ,CAAEA"
}

Above you can see that a source map is an object literal containing lots of juicy info:

• Version number that the source map is based off
• The file name of the generated code (Your minifed/combined production file)
• sourceRoot allows you to prepend the sources with a folder structure – this is also a space saving technique
• sources contains all the file names that were combined
• names contains all variable/method names that appear throughout your code.
• Lastly the mappings property is where the magic happens using Base64 VLQ values. The real space saving is done here.

Base64 VLQ and keeping the source map small

Originally the source map spec had a very verbose output of all the mappings and resulted in the sourcemap being about 10 times the size of the generated code. Version two reduced that by around 50% and version three reduced it again by another 50%, so for a 133kB file you end up with a ~300kB source map. So how did they reduce the size while still maintaining the complex mappings?

VLQ (Variable Length Quantity) is used along with encoding the value into a Base64 value. The mappings property is a super big string. Within this string are semicolons (;) that represent a line number within the generated file. Within each line there are commas (,) that represent each segment within that line. Each of these segments is either 1, 4 or 5 in variable length fields. Some may appear longer but these contain continuation bits. Each segment builds upon the previous, which helps reduce the file size as each bit is relative to its previous segments.

Like I mentioned above each segment can be 1, 4 or 5 in variable length. This diagram is considered a variable length of four with one continuation bit (g). We’ll break down this segment and show you how the source map works out the original location. The values shown above are purely the Base64 decoded values, there is some more processing to get their true values. Each segment usually works out five things:

• Generated column
• Original file this appeared in
• Original line number
• Original column
• And if available original name.

Not every segment has a name, method name or argument, so segments throughout will switch between four and five variable length. The g value in the segment diagram above is what’s called a continuation bit this allows for further optimisation in the Base64 VLQ decoding stage. A continuation bit allows you to build on a segment value so you can store big numbers without having to store a big number, a very clever space saving technique that has its roots in the midi format.

The above diagram AAgBC once processed further would return 0, 0, 32, 16, 1 – the 32 being the continuation bit that helps build the following value of 16. B purely decoded in Base64 is 1. So the important values that are used are 0, 0, 16, 1. This then lets us know that line 1 (lines are kept count by the semi colons) column 0 of the generated file maps to file 0 (array of files 0 is foo.js), line 16 at column 1.

To show how the segments get decoded I will be referencing Mozilla’s Source Map JavaScript library. You can also look at the WebKit dev tools source mapping code, also written in JavaScript.

In order to properly understand how we get the value 16 from B we need to have a basic understanding of bitwise operators and how the spec works for source mapping. The preceding digit, g, gets flagged as a continuation bit by comparing the digit (32) and the VLQ_CONTINUATION_BIT (binary 100000 or 32) by using the bitwise AND (&) operator.

32 & 32 = 32
// or
100000
|
|
V
100000

This returns a 1 in each bit position where both have it appear. So a Base64 decoded value of 33 & 32 would return 32 as they only share the 32 bit location as you can see in the above diagram. This then increases the the bit shift value by 5 for each preceding continuation bit. In the above case its only shifted by 5 once, so left shifting 1 (B) by 5.

1 << 5 // 32

// Shift the bit by 5 spots
______
|    |
V    V
100001 = 100000 = 32

That value is then converted from a VLQ signed value by right shifting the number (32) one spot.

32 >> 1 // 16
//or
100000
|
 |
 V
010000 = 16

So there we have it: that is how you turn 1 into 16. This may seem an over complicated process, but once the numbers start getting bigger it makes more sense.

Potential XSSI issues

The spec mentions cross site script inclusion issues that could arise from the consumption of a source map. To mitigate this it’s recommended that you prepend the first line of your source map with “)]}” to deliberately invalidate JavaScript so a syntax error will be thrown. The WebKit dev tools can handle this already.

if (response.slice(0, 3) === ")]}") {
    response = response.substring(response.indexOf('\n'));
}

As shown above, the first three characters are sliced to check if they match the syntax error in the spec and if so removes all characters leading up to the first new line entity (\n).

@sourceURL and displayName in action: Eval and anonymous functions

While not part of the source map spec the following two conventions allow you to make development much easier when working with evals and anonymous functions.

The first helper looks very similar to the //@ sourceMappingURL property and is actually mentioned in the source map V3 spec. By including the following special comment in your code, which will be evaled, you can name evals so they appear as more logical names in your dev tools. Check out a simple demo using the CoffeeScript compiler.

//@ sourceURL=sqrt.coffee

The other helper allows you to name anonymous functions by using the displayName property available on the current context of the anonymous function. Profile the following demo to see the displayName property in action.

btns[0].addEventListener("click", function(e) {
    var fn = function() {
        console.log("You clicked button number: 1");
    };

    fn.displayName = "Anonymous function of button 1";

    return fn();
}, false);

When profiling your code within the dev tools the displayName property will be shown rather than something like (anonymous). However displayName is pretty much dead in the water and won’t be making it into Chrome. But all hope isn’t lost and a much better proposal has been suggested called debugName.

As of writing the eval naming is only available in Firefox and WebKit browsers. The displayName property is only in WebKit nightlies.

Let’s rally together

Currently there is very lengthy discussion on source map support being added to CoffeeScript. Go check out the issue and add your support for getting source map generation added to the CoffeeScript compiler. This will be a huge win for CoffeeScript and its devoted followers.

UglifyJS also has a source map issue you should take a look at too.

The more tools available to us that can generate a source maps the better off we’ll be, so go forth and ask or add source map support to your favourite open source project.

It’s not perfect

One thing Source Maps doesn’t cater for right now is watch expressions. The problem is that trying to inspect an argument or variable name within the current execution context won’t return anything as it doesn’t really exist. This would require some sort of reverse mapping to lookup the real name of the argument/variable you wish to inspect compared to the actual argument/variable name in your compiled JavaScript.

This of course is a solvable problem and with more attention on source maps we can start seeing some amazing features and better stability.

Tools and resource

Here’s some further resources and tools you should check out:

• Nick Fitzgerald has a fork of UglifyJS with source map support
• Paul Irish has a handy little demo showing off source maps
• Check out the WebKit changeset of when this dropped
• The changeset also included a layout test which got this whole article started
• Mozilla has a bug you should follow on the status of source maps in the built-in console
• Conrad Irwin has written a super useful source map gem for all you Ruby users
• Some further reading on eval naming and the displayName property
• You can check out the Closure Compilers source for creating source maps
• There are some screenshots and talk of support for GWT source maps
• Mozilla has a wiki entry on CSS Source Maps

Source maps are a very powerful utility in a developer’s tool set. It’s super useful to be able to keep your web app lean but easily debuggable. It’s also a very powerful learning tool for newer developers to see how experienced devs structure and write their apps without having to wade through unreadable minified code. What are you waiting for? Start generating source maps for all projects now!

Short URL: http://cssn.in/ja/039

Go check it out! As a thank you for reading I will give away some free passes to the first 10 people who can answer this question correctly: Promotion has now ended, thanks!

“Who created the Modernizr project?”

Mention me on twitter, @ryanseddon, with your answer to the question.

I will let the winners know via twitter.

If you don’t answer in time, don’t fret! It’s super cheap to get access to my course and many others at learnable.com, 2012 is the year of upskilling so get onto it!

Short URL: http://cssn.in/ja/038

Clipboard events

The testcase above hooks into six events that will trigger when the user does a clipboard operation, unfortunately the before[cut/copy/paste] events don’t seem to trigger.

Range objects

Range objects are what you’ve selected on the page allowing you to alter the selection or simply just return what a user has selected. Ranges also allow you to programmatically set a selection within your document, both of these work in iOS safari.

When setting a range iOS Safari won’t actually show the selection as highlighted but if you were to check the document selection it would return the correct content, desktop browsers will show the range selected in the document.

However if you do the same with a user action like tapping the “set selection range” button in the demo the iOS highlight will show up. Another interesting quirk is if I tap the content and bring the keyboard up but don’t dismiss it then refresh the page the programmatically set selection will show the iOS selection highlight.

Another interesting find is if you perform execCommand, which I’ll touch on later in the article, like bold it will apply the command to the selection made and make the iOS selection UI appear.

var sel = window.getSelection(),
    range = document.createRange();

range.setStart($("h1")[0].firstChild, 5);
range.setEnd($("p")[2].firstChild, 50);
sel.removeAllRanges();
sel.addRange(range);

You’ll notice that when selecting an element I get its firstChild, which is a textnode, this is so the offset value will work and allows you to select half a textnode.

The code is saying create a range starting at the documents first h1 element offsetting the selection by 5 characters and ending at the 3rd paragraph offsetting the end of the paragraph by 50 characters.

Setting clipboard data

Accessing the clipboard is an incredibly sporadic task, there is sort of access in some browsers. IE has the most consistent behaviour similar to how DnD data setting works you have a clipboardData interface which has get and setData methods on it. Other browsers have semi-reversed engineered the IE API with the exception that clipboardData is on the event object rather than the window. iOS Safari allows you to get the clipboard data on a paste event but doesn’t allow you to set it.

There is hope that clipboard access will one day have some consistent support through the Clipboard API editor spec but that’s a long way off for now.

In the demo if you’ve copied text from another location and paste it it will alert the clipboard contents before being pasted.

if("clipboardData" in e && e.type === "paste") {
    alert("Clipboard data: " + e.clipboardData.getData('text/plain'));
}

WYSIWYG

By adding support for the contenteditable attribute comes a whole swoth of API’s available for manipulating the contents, one of those is execCommand.

execCommand allows you to do a whole bunch things to the content. Take a look at this great resource which shows all the commands available and its support in the major browsers. These commands allow you to manipulate the style and html of the editable content (this is how all those fancy WYSIWYG editors work).

I would be keen to know if this works on other smart phone browsers, leave a comment if you know more details.

Short URL: http://cssn.in/ja/037

var obj = {
    handleEvent: function() {
        alert(this.dude);
    },
    dude: "holla"
};

element.addEventListener("click", obj, false);

Why is this awesome?

We can do things like this:

var obj  =  {
    init: function() {
        document.getElementById("btn").addEventListener("click", this, false);
        document.getElementById("btn").addEventListener("touchstart", this, false);
    },
    handleEvent: function(e) {
        switch(e.type) {
            case "click":
                this.button();
                break;
            case "touchstart":
                this.button();
                break;
        }
    },
    dude: "holla",
    button: function() {
        alert(this.dude);
    }
};

obj.init();

As you can see our object has an init() method which binds all the events and just passes in “this” as the callback, handleEvent then delegates off to whatever method it needs based on the event being triggered, rad.

But wait there’s more

Another awesome thing we can do is change the buttons behaviour without having to remove and re-attach the event handler. The second button in the demo changes what the first button does by redefining the handleEvent method.

changeHandleEvent: function(evt) {
    this._handleEvent = this.handleEvent;
    // Change the the handleEvent method without needing to remove 
    // and re-attach the event(s)
    this.handleEvent = function(e) {
        var t = evt.target;

        if (t.id === "btn") {
            // Check the button being clicked and do new stuff
        } else if(t.id === "btn3") {
            this.revertHandleEvent();
        }
    }
}

Makes for some pretty powerful stuff. The third button re-instates the first buttons behaviour back to its original form.

This works in nearly all browsers that support addEventListener, Blackberry 6 browser being one that doesn’t. Blackberry OS7 has fixed this bug.

Polyfill it

IE9 was the first to support addEventListener + handleEvent in the IE family, so for the older ones we can polyfill in support for <IE8 and other non-supporting browsers (BBOS6).

// fn arg can be an object or a function, thanks to handleEvent
function on(el, evt, fn, bubble) {
    if("addEventListener" in el) {
        // BBOS6 doesn't support handleEvent, catch and polyfill
        try {
            el.addEventListener(evt, fn, bubble);
        } catch(e) {
            if(typeof fn == "object" && fn.handleEvent) {
                el.addEventListener(evt, function(e){
                    // Bind fn as this and set first arg as event object
                    fn.handleEvent.call(fn,e);
                }, bubble);
            } else {
                throw e;
            }
        }
    } else if("attachEvent" in el) {
        // check if the callback is an object and contains handleEvent
        if(typeof fn == "object" && fn.handleEvent) {
            el.attachEvent("on" + evt, function(){
                // Bind fn as this
                fn.handleEvent.call(fn);
            });
        } else {
            el.attachEvent("on" + evt, fn);
        }
    }
}

For oldIE it checks if the callback is an object and if it contains handleEvent. Using call we can change the “this” context to the object passed.

For BBOS6 we wrap a try catch around addEventListener and if the attaching throws, check the callback is an object and has the handleEvent method otherwise don’t swallow the error.

We handle all this by wrapping up the event attaching into a nice method which handles the process for us.

Resources

I’m certainly not the first to document this, see ajaxian article with some great examples.

Even HTML5 boilerplate mobile uses this technique for their fast touch event handling.

Short URL: http://cssn.in/ja/036

Fullscreen, finally

HTML5 video has come a long way but still lacks consistent codec support and the ability to go fullscreen, until now of course.

As you can see I’ve created a very simple demo showing HTML5 video in full screen, make sure you’re using Chrome dev, webkit or firefox nightly. In Firefox you’ll need to enable it in about:config, search for “full-screen-api.enabled” and set it to true. Webkit nightly will require the “–enable-fullscreen-api” flag when launching. Chrome dev has it enabled by default.

API differences

If you poked around the source you’ll notice that Webkit uses slightly different method to trigger fullscreen. Turns out webkit only uses a different API for videos but uses the same as firefox for all other elements. Mozilla initially created a draft spec for fullscreen elements but Webkit decided to change the name slightly, for the better I think.

var video = document.getElementById("video");

// Mozilla
video.mozRequestFullScreen();

// Webkit for video elements only
video.webkitEnterFullScreen();

As with entering fullscreen you can also cancel it. Using the cancelFullScreen method will exit any element currently in fullscreen mode.

// Mozilla
video.mozCancelFullScreen();

// Webkit
video.webkitCancelFullScreen();

Fullscreen CSS, DOM properties and events

Along with the ability to force a video into fullscreen there is also some CSS pseudo-classes and DOM properties.

video:-webkit-full-screen     { max-height: 100%; }
video:-moz-full-screen        { max-height: 100%; }

The FullScreen API adds one notable pseudo-class that lets you change the element when it’s in fullscreen mode. A good example is if you had a max-height set on your video element and you triggered fullscreen mode you can then reset the max-height to be 100%.

If you want to do something when the browser is in full screen mode the document object gets the fullScreen property. This is slightly different in webkit compared to mozilla.

// Mozilla
document.mozFullscreen;

// Webkit
document.webkitIsFullscreen;

As you can see mozilla doesn’t include the Is in the property like webkit does. So we have this boolean property on the document how do we know when to check it? Well luckily the API also includes an event that triggers called [moz/webkit]fullscreenchange.

video.addEventListener("mozfullscreenchange",function(){
    console.log(document.mozFullScreen);
}, false);

video.addEventListener("webkitfullscreenchange",function(){
    console.log(document.webkitIsFullScreen);
}, false);

The event will trigger whenever fullscreen mode changes so you can then check the document fullScreen property if it’s currently in or out of fullscreen mode. The event is currently prefixed in both Webkit and Firefox.

Some quirks

API differences aside the mozilla spec highly recommends that hitting the Esc key will exit the browser from fullscreen, unfortunately Chrome doesn’t adhere to this (see bug) (Bug has been fixed for linux/windows still needs a fix for mac). If you’re on OSX Lion it will put the browser into full screen mode so to exit you have to hit Cmd+Shift+F on windows F11.

API changes are almost guaranteed. There is already a webkit bug which mentions changing to “Fullscreen” rather than “FullScreen” but for now both are enabled.

UPDATE: There is an official editor draft of the spec and looks like Mozilla’s implementation will be the final one. The API is slighty changing to make FullScreen lowercase in all API calls except where it isn’t the first word e.g. requestFullscreen.

Much more than just video

I only wanted to cover video elements in this article but the API allows fullscreen on almost any element, this functionality is much more limited in Webkit. Webkit uses webkitRequestFullscreen for all other elements. Using the allowfullscreen attribute on iframes for example will allow youtube or vimeo to put their iframe embeds into fullscreen mode. Firefox works with more elements in their nightly build e.g. if you add the mozallowfullscreen attribute to the iframe you can put it into fullscreen mode.

There is also some security restrictions around key events and characters allowed.

Further reading

• Mozilla has a full on demo showing all the support currently in nightly builds, see blog post too.
• Make sure to read over the editor draft spec.
• Apple developer docs mentions support for some of the events and properties.
• Check out MEjs which recently added support for the fullscreen APIs

Short URL: http://cssn.in/ja/035

So what’s different?

The difference between my solution and others is mine requires only a single sprite image and doesn’t need a special media query to keep the images looking sharp in higher dpi screens.

The above demo loads a single sprite image containing all my icons needed. This image is saved with everything double the size of what it should be.

How it works

The way I get it to display nicely for both dpi’s is to use the CSS3 background-size property to shrink it down to the correct size. Since the iPhone 4 naturally scales the image up there is no artefacts or blurriness as the image is already the correct size so you don’t need to use the special media query to make it render nicely.

.ico {
    background: url(ico_sprite-32x32.png) -78px 11px no-repeat;
    background-size: 96px auto; /* 192/2 = 96px */
}
 
.echeck      { background-position: -54px -14px; }
.creditcard  { background-position: -30px -38px; }
.cash         { background-position: -4px -62px; }

If your sprite image is 192px wide then you shrink the width to 96px and set the height to auto to keep the correct aspect ratio. Setting the background-position is also halved so if it’s 108px down you set it too -54px to get the correct offset.

See some comparison images.

iPhone 3GS on the left, iPhone 4 in the middle and Opera Mobile 11 with 291 DPI set on the right

There are drawbacks

Of course this isn’t perfect but in the correct situation is a much better solution. If you need to support older browsers or less capable then background-size won’t work, see background-size support. There is also file size being larger since the sprite image is double the resolution the image is roughly 30-50% larger in size than the smaller counterpart if you’re working with a 8bit png.

Short URL: http://cssn.in/ja/034

Modernizrs’ previous method of injecting the elements revolves around forking for IE, IE<9 uses addRule() rather than insertRule(), this makes it hard to write a simple re-useable method for doing such a test that is cross browser. So I began thinking how this could be re-written to be simplified for re-usability. Rather than inject a style element into the head of a document we could use innerHTML and inject into the element that Modernizr will test against.

elem.innerHTML = "<style>"+css+"</style>";
doc.appendChild(elem);

Simple, easy and certainly re-usable. But something that stumped me for a while is IE6-9 would not append the style element inside the test element?

IE and the case of the NoScope element

After searching high and low I found some useful information about scope and NoScope elements in IE. Basically IE has a few elements that are considered NoScope which when trying to insert with innerHTML will be stripped! On this infamous page however it mentions if you precede a NoScope element with a scoped element they will not be stripped and we can then insert our style element.

elem.innerHTML = scopeElem+"<style>"+css+"</style>";
doc.appendChild(elem);

Huzzah! It works in IE6-9. We now have a simpler easier way to inject an element with associative styles and we've halved our touching of the DOM by bundling the test element and style element into one appendChild operation.

What's considered a scoped element?

A scoped element can be anything other than a style, script or comment element. In Modernizrs' case it uses the soft hyphen entity (&shy;) so as not to interfere with measurements done on the injected element. We could very well prepend the innerHTML string with the test element we wish to inject, but for easier referencing I create it in the method and pass it to the callback. This way we can keep the reference to the node and not have to query the DOM again.

injectElementWithStyles = function(rule,callback){
    ...
    var style, div = document.createElement('div');
 
    style = ['&shy;','<style>',rule,'</style>'].join('');
    div.id = mod;
    div.innerHTML += style;
    docElement.appendChild(div);
 
    ret = callback(div,rule);
    ...
}

There's also a few other additions that centre around the injectElementWithStyles() method such as the test_bundle() method which does the DOM injection test in one fell swoop. If you want to know more go check out the source or hit me up on twitter.

Short URL: http://cssn.in/ja/033

Remy recently added remote debug functionality by the way of an intermediate server to delegate commands, mine works differently and the two solutions could work well together.

In order to use the demo you’ll need to install the BrowserSocket add-on first.

For a quick intro on what you can do, watch the screencast below. I’ll go into how it works on a technical level in the rest of the article. I’ve also filmed a super dodgy looking video of the remote debugging on the iPad.

Browser to browser connections

As mentioned in the intro and screencast this requires the very clever, and awesome, BrowserSocket Firefox addon which allows you to let a browser window act as a WebSocket server that can be connected to by a client using the standard WebSocket API. The beauty of this is it requires very little setup and no actual server, browser to browser communication. In order to communicate with external devices they just need to be on the same local network as your current browser, you can even create an adhoc network between your computer and the device and remote debug that way.

Connecting the client to the console

There a two ways you can connect a client to the jsconsole webapp.

Using the client bookmarklet you can load it on any website and connect to the generated websocket address, make sure the client and the remote device are on the same network. Once an active connection is obtained any console calls will be sent to both the client and the jsconsole webapp, all JavaScript calls will be executed on the client including loading of js libraries.

The second is including the JavaScript file in your project the advantage of this is you can setup automatic connections so any console calls will be sent to the web app.

<script id="jsconsole" 
    data-socketaddress="ws://127.0.0.1:56187/bs/15917705/" 
    src="client.js">
</script>

How it works on a technical level

Once you have installed the BrowserSocket addon in jsconsole you can call the :createServer command which will generate a WebSocket address that you will connect the client to.

:createServer command opens a BrowserSocket instance and gives you a WeSocket address to connect to

Behind the scenes the BrowserSocket addon exposes the BrowserSocket() constructor which uses the nsIServerSocket interface available to Firefox addons to create a socket server with the ability to accept incoming connections.

Using the constructor we create a new instance and supply a connection handler which will initialise the server instance and allow you to attach functions to the various events i.e. onopen/message/close etc same API as WebSockets.

var bs = new BrowserSocket(bsHandler),
     bsConnection;
 
function bsHandler() {
    return new function() {
        bsConnection = this;
        bsConnection.onmessage = function(msg) {
            // Handle messages sent to browsersocket
        }
        bsConnection.onopen = function() {
            // Run stuff once connection is open
        }
        bsConnection.onclose = function(e) {
            // Revert changes once connection is closed
        }
    }
}

On the client side we simply use the native WebSocket API to connect to our BrowserSocket instance upon successful connection it will log a success message to both client and jsconsole webapp. Very simple and very powerful.

var ws = new WebSocket(url);
 
ws.onmessage = function(msg) {
   // Eval code sent from jsconsole
}
ws.onopen = function() {
   // Run stuff once connection is open
}
ws.onclose = function(e) {
   // Revert changes once connection is closed
}

There is one more command called :killServer which does just that, kills the BrowserSocket instance and disconnects jsconsole from the client.

:killServer command kills the BrowserSocket instance and if there is an active connection closes that too

bsConnection.close();
bs.stop();

It’s only the beginning

I have many ideas that I will be implementing such as a :cd command so you can switch between connected device and jsconsole web app. I’ll add a roadmap/ideas wiki on my github fork soon. If you wish to suggest a feature create an issue for now.

I have also created a fork of the BrowserSocket addon on github that will eventually have some minor updates to help with remote debugging such as returning your local ip to make it easier to connect to remote devices. You can check out the master repository on launchpad to follow the actual developments of the addon.

Short URL: http://cssn.in/ja/032

I’ve put the following article ideas into real world practice by using Modernizr as a test subject since it uses a fair amount of the concepts discussed in this article. Make sure your console is open and you’re using a good browser.

Just a side note that since I’m doing some hefty logging and using ternary statements inside some of the logs, the actual execution speed of Modernizr is affected. Always remove logs from production code.

More than just messages

Before we dig into the other console methods let’s show some of the powerful functionality console.log() has, such as the ability to pass as many arguments as you want.

var foo = {baz: "tubular", goo: "rad"}, bar = "baz";
console.log("string",1,foo.goo,bar,foo.baz); // string 1 rad baz tubular

This will print out each argument and display it on the one line. That’s kinda useful but what would be better is if we could somehow intertwine all those arguments into a nicely formatted message in the console. Wait we can.

If you’re familiar with printf() in other languages console.log() shares some similarities. Taking the last example and passing in all those extra arguments we can reference them and create a nicely formatted string.

var foo = {baz: "tubular", goo: "rad"}, bar = "baz";
console.log(
     "%s theory is %d %s concept. I can only describe it as %s and %s",
      "string", 1, foo.goo, bar, foo.baz 
);
// string theory is 1 rad concept. I can only describe it as baz and tubular

What do those %s and %d do?

Glad you asked, these are special characters so we can do string formatting within our log message. Basically %s says print the argument as a string, %d says to print the argument as an integer you can also use %i or %f.

Each appearance of the string formatting operator will choose the corresponding argument. First replacement operator will use the first argument and so on so forth.

We can adjust the order in which an argument will appear within the string by using the $ parameter preceded by the argument we wish to print.

var foo = {baz: "tubular", goo: "rad"}, bar = "baz";
console.log(
     "%2$d theory is %d %s concept. I can only describe it as %s and %s",
     "string",1,foo.goo,bar,foo.baz
);
// 1 theory is 0 baz concept. I can only describe it as tubular and %s string

What this string replacement is saying is I’ll start at the second argument and progress from there which as you can see causes an issue.

Essentially the first argument gets appended to the end of our arguments giving us six arguments but we only specified five locations for the strings to be replaced in and since we started at argument two it only prints four of them followed by %s and string.

We can fix this by adjusting the above log message and reset the position so everything will be printed as expected.

var foo = {baz: "tubular", goo: "rad"}, bar = "baz";
console.log(
     "%2$d theory is %1$s %3$s concept. I can only describe it as %s and %s",
     "string",1,foo.goo,bar,foo.baz
);
// 1 theory is string rad concept. I can only describe it as baz and tubular

In order to get the arguments to print out correctly we need to change the starting order of the second and third replaced items. The others are in the correct order so we don’t need to adjust where they should start looking. The string will use the arguments in this order 2,1,3,4,5.

String formatting is a powerful tool and I’ve only scratched the surface. Try experimenting to see what you can get it to do and take a read of some of Joe Hewitts docs on the console.

Different kind of messages

Like log there a few other methods that will allows us to present a message to the console with different styling. Those are console.info(), console.warn() and console.error().

console.info("%s numbers %d, %d and %d","hello",1,2,3); // hello numbers 1, 2 and 3
console.warn("%s numbers %d, %d and %d","hello",1,2,3);
console.error("%s numbers %d, %d and %d","hello",1,2,3);

Firebug example of console.info(), console.warn() and console.error()

All three can also use string formatting and be passed as many arguments as you want. These can obviously give you much clearer visual clues as to what is going on in your code.

Logging the DOM

When you log a reference to a DOM element the default behaviour is to provide a link to that DOM element with console.dir() and console.dirxml() methods we can inspect the elements properties or create a little subset of the html outline of the element.

console.dir(document.documentElement);
console.dirxml(document.documentElement);

Chrome example of console.dir() and console.dirxml()

Grouping

Sometimes it would be useful to be able to group a bunch console calls for easier referencing we can do that with console.group(), console.groupCollapsed() and console.groupEnd().

console.group("Overlord");
console.log("Overlord stuff");
 
console.group("Lord");
console.log("Overlord stuff");
 
console.group("Minion");
console.log("Minion stuff");
console.groupEnd();
 
console.groupCollapsed("Servant");
console.log("Servant stuff");

Safari example of console.group() and console.groupEnd()

As you can see nesting console.group() will further nest the results, in order to end a particular group you use the console.groupEnd(). console.groupCollapsed() is the same as console.group() but the group and its related information will be collapsed.

Code timing and profiling

The console also allows you get fairly accurate timings useing console.time() and console.timeEnd(). These two methods need to be placed at the start and end of what you want to time in your code.

console.time("Execution time took");
// Some code to execute
console.timeEnd("Execution time took");

Firefox example of console.time() and console.timeEnd()

The timers are associated with each other via their labels, this way you can have multiple timers throughout your code. When a timer hits a console.timeEnd() it will output a message with your label and the time it took in milliseconds to execute.

Along with timings we can also profile a subset of your code and output the profile stack, giving lots of juicy information about how much time the browser spent where.

console.profile();
// Some code to execute
console.profileEnd();

Asserting your code

When you begin working on a complex project it’s important to start unit testing your code. This allows you to avoid simple mistakes and possible regressions. Luckily the console also includes assertions.

Assertions allow you to enforce rules in your code and to make sure the results it’s producing are the results you expect. The console.assert() method allows us to do rudimentary unit tests on our code, if something fails the console will throw an exception. The first argument can be anything, function, equality check or checking existence of an object.

var a = 1, b = "1";
console.assert(a === b, "A doesn't equal B");

Chrome example of console.assert()

The assert method takes the assertion you want to enforce as the first argument, in this case a simple strict equality check, and the second argument is the message to display if it fails.

Browser support

Most of the following console methods discussed have quite good browser support. IE8+, Firefox with firebug, Opera or a webkit browser such as Safari or Chrome. There are a few differences between the browsers, Firefox, Safari and Chrome having the widest support. A good way of finding support is to do console.dir(console) which gives you nice look at the console object and it’s methods.

Opera with Dragonfly does support most of the methods on the console with the exception of string formatting so no fancy logging with argument re-ordering in dragonfly. There is no timing but no profiling (although there is profile and profileEnd available it will log saying this feature is not yet available).

iOS Safari also has pretty rubbish support, no string formatting, timing, profiling or grouping but the limited screen real estate could be the reason some of these aren’t supported. It does however support assertions.

IE8 has support for a pretty wide range too including string formatting and assertions but no timing, profiling, dir or dirxml.

Having said that using firebug lite can add some of the console methods to unsupporting browsers.

I haven’t discussed everything available in the console but what I did cover would be the most useful features available to make debugging and testing a much smoother process. Go forth and enrich you development with more than just string logging.

Short URL: http://cssn.in/ja/031