It simply boils down to using LiveReload on the page, using DevTools with the “Save As” functionality on the CSS, then simply make the change on the desktop using DevTools, which automatically saves to file, which causes LiveReload to trigger a reload on all devices (perhaps frustratingly on the desktop too), but also the remote devices – mobile or otherwise – to refresh allowing me a quick glance to make sure the styles look right.

Simple.

What it should be

There is an ideal workflow, and I believe this is the way it’s supposed to work (but maybe the browser isn’t quite there just yet, but it feels like it’s just around the corner).

You connect your mobile browser (Android Chrome in this case), run adb (and I think I saw a browser extension that makes this easy during some of the Google IO 2013 videos), open Chrome (Canary works) and navigate to chrome://inspect and you’ll be able to launch the devtools for that page.

From those devtools I imagine I should be able to edit and save to disk and it would remove the requirement for LiveReload (though this doesn’t solve working with iOS). Pretty cool.

Related posts:

1. My Workflow: Never having to leave DevTools
2. Mobile Battery Performance
3. T-Mobile allow free Wifi Google Maps

tracegl was so much more than I realised: it captures full JavaScript state a all points of my application’s execution – both on the server side, but also the client side.

Debugging a real bug with tracegl

Rik Arends includes an introductory video on the site, and the script is €12 – which frankly is a steal for what it provides me. If you’re join my Node workshop – I’m proving a licensed copy for everyone (because I think it should be part of your core stack).

I’ve included a short video of how I’ve used tracegl to debug my server side application. A few important things to note are: the trace is historical – and not blocking execution, which is what I’d normally do if I had to debug: I’d carefully replicate the issue, then either add a conditional breakpoint or debugger statement – but with tracegl, the bug can occur, and if tracegl is running, I can just look back at the state of the problem.

Learning more

I’m running a new crash course in Node on July, and similar the past it’s known to have sold out in a week. Tickets go on sale on Wednesday at 10am (UK) and will be available here.

I’ll be using this tool and many others to give you a fully packed day of knowledge on how to use Node, how to develop sites and real-time applications, and what tools I use for debugging, publishing and deployment.

So grab a ticket if you want my hands on, “knowledge smash & grab” course (or check out more details here).

Related posts:

1. JS Bin for Collaborative JavaScript Debugging
2. Full Frontal 2012 launches soon!
3. Full Frontal JavaScript Conference

7 years ago…

17-Jun 2006, I publish my first (ever) real blog post: taking regular JavaScript and simplifying to jQuery syntax. It turned 14 lines of JavaScript in to 3 lines of jQuery (pre jQuery 1.0).

Most importantly, it went from some fiddly DOM navigation to a simple CSS expression, and added a class once done. The original JavaScript was also quite brittle, so it meant you either had the same markup.

I introduced jQuery to the team of developers I worked with back in mid-2000s and even the designers could see the appeal (since they generally understood CSS selectors (and hence how jQuery for Designers was born)).

DOM navigating was suddenly easy

Back then the DOM was hard to navigate. You could be sure that if it worked in Firefox 1.5, it wouldn’t work in IE6.

The ease in which jQuery could be learnt was the appeal to me. All the DOM navigation was done using CSS expression using some insane black box magic that John Resig had come up – saving my limited brain power, and once I had those DOM nodes, I could do what I wanted to them (usually some combinations of showing, hiding, fading and so on).

Groking ajax

jQuery also abstracted ajax for me. The term had only just been coined earlier in 2005, but documentation was not wide, nor trivial to understand (remember the lower power computing power of my brain).

It was the first time I really had to deal with the XMLHttpRequest object, and when seeing it for the first time, understanding the onreadystatechange event and the combination of this.status and this.readyState wasn’t overtly clear! jQuery (and other libraries) also tucked away the mess that was XHR in IE via ActiveX…

function getXmlHttpRequest() {
  var xhr;
  if (window.XMLHttpRequest) {
    xhr = new XMLHttpRequest();
  } else {
    try {
      xhr = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
      try {
        xhr = new ActiveXObject("Microsoft.XMLHTTP");
      } catch (e) {
        xhr = false;
      }
    }
  }
  return xhr;
}

// disclaimer: John's jQuery version is a lot more elegant!

Once I could see that using the ajax utility inside of jQuery to suck in a URL’s HTML (which was typically the way we wanted to do ajax), then ajax suddenly clicked.

jQuery quickly became my standard utility for many years. It was my Swiss Army Knife, as it were, to steal Adam’s talk title!

Back to the future: today

Let’s fast forward back to today. What’s happened over those years?

For starters, my default starting position is no longer “include jQuery by default”. I understand more JavaScript and how things work.

I have my own criteria for when to include jQuery, and when not to include jQuery. But if I don’t include jQuery, then what?

In those 7 years, quite a bit has happened. Probably one of the most important steps forward was the introduction of querySelectorAll.

Being able to give a native function of a browser a CSS expression, and it doing the work to navigate the DOM is a huge (literally) part of jQuery. Basic support was in Chrome from the outset, and in IE8 and Firefox 3.5 around mid-2009.

Andrew Lunny (of PhoneGap & Adobe) has the brilliant simplicity on the bling function:

var $ = document.querySelectorAll.bind(document);
Element.prototype.on = Element.prototype.addEventListener;

$('#somelink')[0].on('touchstart', handleTouch);

Beautifully simple.

I’ve taken this idea a little further and used it on a few specific projects, adding support for chaining, looping and simplifying the syntax. Comes in at <200 bytes gzipped. But the point is that today we have features natively available, and I’m trying to consider my audience before dropping in jQuery by default.

When I always use jQuery

Before I look at how I can go without jQuery, naked, let me just share when I drop jQuery in to a project. There’s usually a few of very specific criteria that either has me start with jQuery or switch from a bespoke solution in favour of jQuery.

Before I do, I should point out when I absolutely don’t use jQuery: If I’m trying to replicate a browser bug, I never use a library. If you’re trying to corner a bug, so that you can file an issue, you want your case as minimal as possible (unless of course you’re filing a bug on jQuery!).

1. When the project has to work in non-cutting-mustard browsers

The BBC have been quite vocal in what they define as “cutting the mustard“, and now I think about it, that’s my benchmark for when to include jQuery by default.

If I know I have to work with browsers that don’t cut the mustard, and they’re part of the core audience, then I’ll start with jQuery in my initial code.

What is cutting the mustard?

It’s almost as simple as: does this browser have querySelectorAll?

The BBC use the following test for cutting the mustard:

if ('querySelector' in document && 
    'localStorage' in window && 
    'addEventListener' in window) {
    // bootstrap the JavaScript application
}

I know off the top of my head IE8 doesn’t support addEventListener (but there is a polyfill), so if that’s an important browser to the project, then I know that I don’t want to start the project hoop jumping for IE8.

This isn’t to say those projects that I start without jQuery won’t support IE8, it’s more that you want to start simple, and keep development simple from the outset. If I start a project with a bag of hacks – I know it’s going to be a hassle.

I also class this as “when complexity outweighs ease”.

2. When it’s quick and dirty

If I’m creating a proof of concept, testing an idea out, and generally hacking and creating a JS Bin, I’m usually adding jQuery by default. It saves me thinking.

jQuery-free

You might be thinking “so, does Remy use jQuery, and if he doesn’t then does he just re-implement it all?”.

I certainly don’t want to re-invent the wheel. If I find that developing without jQuery only leads me to re-creating a lot of jQuery’s functionality from scratch, then I’m clearly wasting my own time.

No, there’s a lot of patterns where I will build my application code without a library and rely on native browser technology to do the job. And if there’s a small part of that functionality missing, I might turn to polyfills – but only after careful review that it makes sense.

So how do I live without jQuery, and how good is the support?

document.ready

Even when I use jQuery, if I (or my company) have control of the project, I very, very rarely use document.ready (or the shortened version $(function)).

This is because I put all my JavaScript below my DOM, before the </body> tag. This way I always know the DOM is going to be compiled by this point.

Hopefully it’s common knowledge by now, but JavaScript blocks rendering. Put your JavaScript above the content, and your server stalls, and you get a blank page. I’ve used this example many times before, but twitter’s “badge” (a long time ago) used to be put inline to your HTML. Their site would often go down, and as my blog (also carrying the twitter badge) would hang with a blank page – giving the appearance that my site was down.

.attr(‘value’) and .attr(‘href’)

It makes me sad when I see jQuery to retrieve a value from an input element:

$('input').on('change', function () {
  var value = $(this).attr('value');

  alert('The new value is' + value);
});

Why? Because you can get to the value using this.value. More importantly – you should think about how you’re using a JavaScript library. Don’t unnecessarily invoke jQuery if you don’t need to.

In fact, this isn’t a jQuery thing – it’s a best practise thing. The code should simply read:

$('input').on('change', function () {


  alert('The new value is' + this.value);
});

It’s also common to use jQuery to get the href of an anchor: $(this).attr('href'), but you can also easily get this from knowing the DOM: this.href. However, note that this.href is different, it’s the absolute url, as we’re talking about the DOM API, and not the element. If you want the attribute value (as it’s suggested in the jQuery version), you want this.getAttribute('href').

Then there’s setting the class on an element, you don’t need jQuery for that either if you’re just adding a class.

I’ve seen this before:

  <script src="http://code.jquery.com/jquery.min.js"></script>
</head>
<body>
  <script>
    $('body').addClass('hasJS');
  </script>

But why not:

</head>
<body>
  <script>
    document.body.className = 'hasJS';
  </script>

Probably the most important change in the version below, is there’s no jQuery being included first just to set a class name on the body to determine whether JavaScript is available.

If the body might have a class already, just append (jQuery has to read the className property too): document.body.className += ' hasJS'.

And this is where we start to run in to issues with class names and tracking what classes they have and don’t have. But browsers have this functionality natively too.

classList for add, remove & toggle

HTML5′s classList support is in all the latest production browsers (note not in IE9 – but this is a case where I might choose to polyfill).

Instead of:

$('body').addClass('hasJS');

// or

document.body.className += ' hasJS';

We can do:

document.body.classList.add('hasJS');

Isn’t that pretty?

What about removing:

$('body').removeClass('hasJS');

// or some crazy ass regular express

Or we can do:

document.body.classList.remove('hasJS');

But more impressive is the native toggle support:

document.body.classList.toggle('hasJS');

// and

document.body.classList.contains('hasJS');

To set multiple classes, you add more arguments:

document.body.classList.add('hasJS', 'ready');

What does suck though, is the weird issues – like don’t use a empty string:

document.body.classList.contains('');
// SyntaxError: DOM Exception 12

That’s pretty rubbish. But! On the upside, I know the problem areas and I avoid them. Pretty much what we’ve grown up on working with browsers anyway.

Storing data

jQuery implemented arbitrary data storage against elements in 1.2.3 and then object storing in 1.4 – so a little while ago.

HTML5 has native data storage against elements, but there’s a fundamental difference between jQuery and native support: object storage won’t work in HTML5 dataset.

But if you’re storing strings or JSON, then native support is perfect:

element.dataset.user = JSON.stringify(user);
element.dataset.score = score;

Support is good, but sadly no native support in IE10 (though you can add a polyfill and it’ll work perfectly again – but that’s a consideration when using dataset).

Ajax

Like I said before, jQuery helped me grok ajax fully. But now ajax is pretty easy. Sure, I don’t have all the extra options, but more often than not, I’m doing an XHR GET or POST using JSON.

function request(type, url, opts, callback) {
  var xhr = new XMLHttpRequest(),
      fd;

  if (typeof opts === 'function') {
    callback = opts;
    opts = null;
  }

  xhr.open(type, url);

  if (type === 'POST' && opts) {
    fd = new FormData();

    for (var key in opts) {
      fd.append(key, JSON.stringify(opts[key]));
    }
  }

  xhr.onload = function () {
    callback(JSON.parse(xhr.response));
  };

  xhr.send(opts ? fd : null);
}

var get = request.bind(this, 'GET');
var post = request.bind(this, 'POST');

It’s short and simple. XHR is not hard and it’s well documented nowadays. But more importantly, having an understanding of how it really works and what XHR can do, gives us more.

What about progress events? What about upload progress events? What about posting upstream as an ArrayBuffer? What about CORS and the xml-requested-with header?

You’ll need direct access to the XHR object for this (I know you can get this from jQuery), but you should get familiar with the XHR object and it’s capabilities, because things like file uploads via drag and drop is insanely easy with native functionality today.

Finally forms!

The jQuery form validation plugin was a stable plugin from the early days of jQuery, and frankly made working with forms so much easier.

But regardless of your client side validation – you must always run server side validation – this remains true regardless of how you validate.

But what if you could throw away lines and lines of JavaScript and plugins to validate an email address like this:

<input type="email">

Want to make it a required field?

<input type="email" required>

Want to allow only specific characters for a user?

<input pattern="[a-z0-9]">

Bosh. It even comes with assistive technology support – i.e. the keyboard will adapt to suit email address characters.

Since these types fall back to text, and you have to have server side validation, I highly encourage you to rip out all your JavaScript validation and swap in native HTML5 form validation.

jQuery animations VS. CSS animations VS. JavaScript animations

It’s not really a contest. CSS wins. Animating using CSS is being processed on the GPU. Animating in JavaScript has the additional layer of computation in the simple fact there’s JavaScript.

Even then, if I’m writing the code myself, I’m going to choose to use requestAnimationFrame over setInterval based animations.

Jake Archibald has some excellent slides showing the issue here, whereby setInterval won’t be smooth and will quickly start to drop frames:

What’s more, CSS animations go through the same scheduler as requestAnimationFrame, which is what we want to use.

So if your browser support allows for it, use CSS animations. Sure, it’s not as easy as $foo.animate('slow', { x: '+=10px' }) but it’s going to be cleaner and smoother. It should be a well known fact that touching the DOM is expensive. So if you’re animating the x position of an element by updating the el.style.left attribute, you’re going back and forth for the animation.

However, if you can simply do foo.classList.add('animate'), the CSS class animate will transition the left position of the element. And you have control if that’s just the left property, or if you take advantage of hardware acceleration by using translateX with translateZ(0).

But what about my animation end callback I hear you all cry?! That’s available too. Though it’s a little icky:

el.addEventListener("webkitTransitionEnd", transitionEnded);
el.addEventListener("transitionend", transitionEnded);

• Note the the lowercase ‘e’ on ‘end’…

A few kind people on twitter did also point me to a sort-of-polyfill for jQuery, that enhances the .animate function if CSS animations are available.

There’s also a separate plugin called Transit which gives you JavaScript based control over creating CSS animations. A really nice aspect (for me) is the chaining support. Since it relies exclusively on CSS animations, it requires IE10 and above.

Which begs me to ask: why does this plugin require jQuery specifically?

Aside: jQuery plugins – just because.

Me:

I don’t know why, but I really want to hurt the people who write jQuery plugins that don’t really need jQuery. /seeks-anger-management

Reply:

@rem Me too, I suspect there’s a support group for that. Probably rather large.

I was working on a project recently, and knew of the fitText.js project. I went to drop it in, but then spotted that it needed jQuery.

Hmm. Why?

It uses the following jQuery methods:

1. .extend
2. .each
3. .width
4. .css
5. .on (and not with much thought to performance)

The plugin is this:

  $.fn.fitText = function( kompressor, options ) {

    // Setup options
    var compressor = kompressor || 1,
        settings = $.extend({
          'minFontSize' : Number.NEGATIVE_INFINITY,
          'maxFontSize' : Number.POSITIVE_INFINITY
        }, options);

    return this.each(function(){

      // Store the object
      var $this = $(this);

      // Resizer() resizes items based on the object width divided by the compressor * 10
      var resizer = function () {
        $this.css('font-size', Math.max(Math.min($this.width() / (compressor*10), parseFloat(settings.maxFontSize)), parseFloat(settings.minFontSize)));
      };

      // Call once to set.
      resizer();

      // Call on resize. Opera debounces their resize by default.
      $(window).on('resize orientationchange', resizer);

    });

  };

.extend is being used against an object that only has two options, so I would rewrite to read:

  if (options === undefined) options = {}; 
  if (options.minFontSize === undefined) options.minFontSize = Number.NEGATIVE_INFINITY;
  if (options.maxFontSize === undefined) options.maxFontSize = Number.POSITIVE_INFINITY;

return this.each used to loop over the nodes. Let’s assume we want this code to work stand alone, then our fitText function would receive the list of nodes (since we wouldn’t be chaining):

  var length = nodes.length,
      i = 0;

  // would like to use [].forEach.call, but no IE8 support
  for (; i < length; i++) {
    (function (node) {
      // where we used `this`, we now use `node`
      // ...
    })(nodes[i]);
  }

$this.width() gets the width of the container for the resizing of the text. So we need to get the computed styles and grab the width:

  // Resizer() resizes items based on the object width divided by the compressor * 10
  var resizer = function () {
    var width = node.clientWidth;

    // ...
  };

It’s really important to note that swapping .width() for .clientWidth will not work in all plugins. It just happen to be the right swap for this particular problem that I was solving (which repeats my point: use the right tool for the job).

$this.css is used as a setter, so that’s just a case of setting the style:

  node.style.fontSize = Math.max(...);

$(window).on('resize', resizer) is a case of attaching the event handler (note that you’d want addEvent too for IE8 support):

  window.addEventListener('resize', resizer, false);

In fact, I’d go further and store the resizers in an array, and on resize, loop through the array executing the resizer functions.

Sure, it’s a little more work, but it would also easy to upgrade this change to patch in jQuery plugin support as an upgrade, rather than making it a prerequisite.

Rant will be soon over: it also irks me when I see a polyfill requires jQuery – but I know the counter argument to that is that jQuery has extremely high penetration so it’s possibly able to justify the dependency.

Closing

My aim was to show you that whilst jQuery has giving me such as huge helping hand over the years (particularly those years of poor interoperability), that native browser support is a long way to doing a lot of the common workflows I have when writing JavaScript to “do stuff” to the DOM.

Forget about X feature doesn’t work in Y browser – approach it from the point of view of: what am I trying to solve? What’s the best tool for the job? What’s my audience?

I still believe in progressive enhancement, but I don’t believe in bending over backwards to support an imaginary user base (because we don’t have data to say what browsers our users are using).

Google (last I read) support latest minus 1. I try to start from the same baseline support too.

I’ll continue to use jQuery the way that suits me, and I’ll continue to evangelise that front end devs learn what the browsers they work with are capable of.

With that then, I close, and I hope this has been helpful to you.

Maybe some of you knew all this already (though I would question why you’re attending/reading this!), hopefully I’ve shown some of you that there’s a world beyond jQuery and that you can start using it today in some of your projects.

Maybe some of you are new to jQuery – I hope that you go on to look further in to what JavaScript and the DOM are capable of.

But for the majority of you: I’m singing to the choir. You’re already invested. You already believe in standards, doing it right, learning and bettering yourself. It’s those people who aren’t getting this information that you need to help.

You need to share your experiences with the others around you. You’re the expert now, and it’s up to you to help those around you, to help them come up to your standards and beyond.

Conferences will be looking for new speakers, new experts: you are that person.

Related posts:

1. jQuery multibinding events
2. jQuery API Browser
3. How to tell if jQuery is out of date

One thing that always bugged me about dynamic popup windows when compared to dynamic iframes: you need a separate .html file to use as the target of the popup. I’ve documented this process because it might help someone else. I’m not saying you should use these methods, method 2 is particularly distasteful – I’m just sayin’: you can!

Here’s two methods where you don’t need a separate file.

Why do you want a dynamically generated popup?

For me there was a very specific situation, but one I’ve come up against in the past is bookmarklets (and userscripts). If you have a bookmarklet, it’s likely that the single JavaScript file (or inline code) will include the entire application. If you need a popup, then you need a static HTML file, which then also means you need to host said file.

If you can generate the popup target file on the fly, the code can remain entirely inside your JavaScript file and it has zero dependencies.

I’m just documenting what I did in case there’s any other folk trying to pull off the same trick.

Method 1: using a data url

The data url, a beautiful thing:

The data URI scheme is a URI scheme that provides a way to include data in-line in web pages as if they were external resources

Source: Wikipedia

One common use of the data url is inline images in HTML or CSS files, usually looking something like:

data:image/png;base64,iVBORw0KG......

You can also use this same technique for HTML files too:

data:text/html,<title>Hello Data URL</title><p>File-less HTML page!</p>

With that, it means we can dynamically generate a popup window without a .html file clogging up our mojo:

window.open('data:text/html,<title>Hello Data URL</title><p>File-less HTML page!</p>', 'Hello World', 'width=400,height=200');

This works perfectly if all you want is a dynamic popup (that’s supported in IE8 and others).

However, if you want that popup to talk to the parent window that generated the popup in the first instance (which in my case was true), you’re outta luck since the data url origin does not match the origin of the domain that created the popup, which basically equals no dice. So that’s how I got the craziness you’re about to see.

Method 2: using the parent page as the popup child

Um, what? This solution uses the HTML file that creates the popup as the target of the popup. Once open, the popup nukes the DOM and rewrites it with it’s own.

It’s not a pretty solution, but works in some cases (mine in particular) and has the distinct advantage that the popup resides on the same domain as the parent, and thus allowed to talk directly to it.

I should add that this method works for scripts that have been hardcoded in to the user’s page. A plugin or a browser userscript would match this particular situation.

A couple of additional caveats in an already crazy sounding solution are:

1. You need some kind of identifier on the url to indicate this is the popup version
2. Any JavaScript that’s executed before your script is encountered will be executed. If you can make sure your script is first, you can prevent the successive scripts from running.

One single script is included as the first script include on this page with the following code (and demo):

if (window.location.hash.indexOf('#popup') === -1) {
  window.open(window.location + '#popup', 'Popup', 'width=300,height=300');
} else {
  // we are the popup
  initPopupClient();
}

function initPopupClient() {
  // here we're overwriting the contents of the HTML element
  // causing any successive scripts to be removed - thus if
  // we can be first, it's a good thing.
  document.documentElement.innerHTML = [
    '<title>Popup tool</title>',
    '<style>* { font-family: comic sans; }</style>',
    '<p>Welcome to our dynamically generated popup</p>'
  ].join('');

  // now trigger any function on our parent window
  window.opener.alert('Hello from the popup');

  // or send it messages nicely
  window.opener.postMessage('This is less invasive I guess!');
}

Trashing the original DOM.

Since we’re using the parent page as the popup source, we need to remove the DOM entirely and replace it with ours. By overwriting the contents of the HTML element we succeed in doing that:

document.documentElement.innerHTML = ...some new markup...

Here’s a simple example that only shows one sentence and doesn’t include the alert (view the source to see what you were supposed to get).

Referring to the parent window

We do this in the regular way of accessing the opener property. This allows us direct access to any method, and if you’re going to be nice, you’ll just use the postMessage allowing the parent to just listen for message events:

window.opener.postMessage(JSON.stringify(someData));

Disclaimer

Both these techniques are pretty extreme and you should consider you have good reason to actually use them. For my particular problem (which should be detailed in my next post) it was a necessary evil. Make sure you really don’t want that hosted .html file! The only reason I came to this conclusion (of crazy hoop jumping) was because of my requirements for remote-tilt.com‘s polyfill script.

Related posts:

1. JSONP request in Adobe Air
2. Wiki to HTML using JavaScript
3. What is JSONP?

But! Instead, as a nice thing™, I’d like to send one of you.

I’d like to send someone who’s new to the web industry and wouldn’t normally be able to afford this kind of conference.

I’ll foot the bill for your ticket (Tom’s discount will go towards it too) but you’ll need to arrange your own travel and any necessary lodgings.

I’ll pick someone at random on Wednesday 27th at 12pm.

So please volunteer yourself, or even volunteer someone you know that you think is deserving. I will be on the look out for things like your blog, any git repo – that all counts towards whether you make it in the hat. Pop a comment below (or contact me directly) with your name and why you should go, and I’ll start adding names to my hat to later pull one lucky candidate of out.

And you never know, you might even discover your next big client or employer at the conference!

Related posts:

1. Win a ticket for the Full Frontal JavaScript Conference
2. Full Frontal JavaScript Conference

I’m left with the decision do I clone the project locally and fire up my own server, look at it, then shortly after delete it as I was only planning to browse…or something else?

How about “quick preview”? So I built that in a few hours last month: 5minfork.com.

Sure, I know this isn’t really a fork, but 5 minute clone didn’t have the same ring to it!

The idea

The concept is simple, but requires a non-blocking server if I wanted to make the service public – which I’ll explain why in a moment:

1. It needed to be simple to go from github repo url to this preview system.
2. The previewed fork needed to be served from the root of the hostname, because it’s likely the resources in the repo would run off absolute paths.
3. I wanted the previews to automatically clean themselves up, so I didn’t end up chomping loads of disk space.
4. Cloning a project should not take down the server!

I knew this should be simple with Node.js mostly because I needed to send off the clone process in the background (to the main application) and only once it’s returned, do I serve up the forked content.

The way it works

Using the connect library I have my own custom router that does most of the work.

Then clones are spawned out to a separate process, and once completed, a unique hash is created as a new subdomain for the server with it’s own router pointing to the new clone. After 5 minutes of idle time, the clone is automatically removed and cleaned up.

Repo router

When you request anything off the default root of the server, it assumes (unless the resource is found in the public directory) that you’re referring to a github repo, ie. https://github.com/remy/5minfork

The problem was that usernames and repos are case sensitive, but urls aren’t. So when you redirect to the subdomain (which I wanted to be remy-5minfork), it wouldn’t work, because subdomain switch to lowercase, and now it doesn’t know the difference between 5MINFORK and 5minfork. So to get around this, a hash is made for the path, stored in a JavaScript object in the server, and immediately redirected to http://<hash>.5minfork.com.

This subdomain then looks up the original github repo url, and kicks off the fork process.

Forking (actually cloning…)

I apologise for my interchangeable use of fork & clone – blame github (apparently).

My exceptionally short fmf.js script works out the github repo url, and spawns a fork. Once all the spawn’s data has ended, it triggers the callback, that tells my server the fork was successful.

Dynamic router

This is the “clever bit” (given how short the code is, don’t expect to be wowed).

A new router is created for this specific fork, and stored against the hashed url (so we know when we hit http://abc321.5minfork.com it has a bunch of info associated with it).

Then with that new router, it passes the original request and response objects, which then handle the entire http request – thus being able to serve up the static previewed repo.

The new router is made up of the static router, and the directory router (specifically because most repos without a preview, don’t have an index.html page).

The final bits

You might think I was using the vhosts connect module, but I’m not, a simple bit of middleware is parsing the host out of the request header and making up the req.subdomain property, which I use to match up to the hash that links to the repo data.

A simple timer fires every 10 seconds to see when the repo was last accessed, and if that difference is more than 5 minutes, it blows away the directory.

Like I said, quick and dirty.

Of course all the code is up on github. Hopefully this write up or the tool itself is useful to you, I know I’ve already started using it. Now all I need is a little browser plugin to add a preview icon next on the github repo page, so it’s even faster to get the 5 minute fork!

Related posts:

1. Slicehost, Node.js & WebSockets
2. node.js rapid development: nodemon
3. A Public MIT License Resource

Access-Control-Allow-Origin: *

Should you be adding this header to your existing API services? Yes.

If you want more details on how it works check out this HTML5 Rocks article and make sure to watch out for preflight issues.

But this post isn’t about CORS for XHR, it’s about CORS for images. CORS for images is important for remixing content and sites such as Flickr, Instagram, Imgur and the like.

What use is CORS for images?

(As far as I know) there’s one major use case: when you’re creating a dynamic canvas image and you want to export it. The canvas element has a method called toDataURL which gives you a base64 string representing the content of the canvas.

Perhaps you’re creating a collage of your flickr photos and want to print that collage out. More specifically, in my case, I’ve been taking a photo a day for 3 years, and I wanted to print the entire collection out on a material canvas. I use the canvas API to generate my image, but I can’t export it.

That’s to say, if you use canvas API method drawImage to paint a flickr photo (perhaps even your own) on to a canvas element, you can’t use getImageData to further manipulate the pictures, nor can you use toDataURL because the url your script executed on is not the same origin* as the flickr photo.

* origin, which is made up of the protocol, host and port number.

The solution to allowing us to export our canvas creations is to enable CORS from the source origin. Simply adding the Access-Control-Allow-Origin header when an image requests origin rights.

So in my case, where I wanted to generate a file to be sent to the printers, I moved my code to using Node.js (which I’ll post about in detail another day). Couldn’t do the export in the browser – but I should have been able to.

How to request images with CORS

You have to set the crossOrigin attribute, which can be set via HTML attributes or via JavaScript.

A blank value (as an HTML attribute) has the default value of anonymous – which is likely what you want. Alternatively you can set this to use-credentials which sets the credentials request header – which the server can use to decide whether you have rights to the content.

When the CORS headers are sent back from the server for an image, and that image is used on a canvas, the origin-clean flag is true, and we are able to remix the content as we please.

Below you can see a simple working example. The script reads the image element, draws and scales it to a new canvas, then creates a circular version of the picture, and it’s then exported to a new real image element, and finally the original image is replaced with the cirlified image. The source image is hosted on http://rem.io (the <img> element with the crossOrigin attribute at the top of the HTML) but the image remixing is happening on http://jsbin.com (as an embed on this site via an iframe). This is all possible with CORS support.

canvas resizer

Go forth!

So if you happen to work at a company, or know someone that works at a company that hosts user images – please please add CORS support to your images (if an origin header is sent in the request).

Go, go make that change, now!

Related posts:

1. Getting CORS Working
2. Dynamic favicons
3. JSONP request in Adobe Air

Professional

I run my own consultancy/agency/what-have-you, called Left Logic. My aim is to specialise in JavaScript based development, and as the years have gone on, that aim is starting to fruition. All our current client endeavours are either client-side JavaScript or server-side Node.js based JavaScript.

More importantly, I’m growing my company (more on that in a moment) so if you’re a business that needs our help: get in touch.

Business

From when I started my business back in September 2006, I told myself the sweet spot I was aiming for was 6 people (including myself). For the first 5 years employee head count remained at 1 – just me. Although I’ve contracted Jon Linklater Johnson for the best past of 3 years – so let’s say 1.75 people.

This September, Julie joined Left Logic full time (though she spent the last 3 years organising and running Full Frontal and running accounts). She’s now our full time events organiser and company logistics person.

Then quickly after Tom Ashworth joined Left Logic as a full time developer. A talented young developer from Cardiff Uni already having an impact on some of the work Left Logic produces (both client work and open source projects). I’m very excited to have him join Jon, Julie and myself at Left Logic.

As my company grows, I’m also looking for more client projects to challenge our work. Left Logic will of course always continue to contribute to open source projects (like JS Bin).

Speaking

I spoke at 12 events this year, across England, Germany, Italy, Netherlands, Norway and the United States. I’ve been actively trying to keep my travelling down to no more than once a month – to keep near family (and also bringing Julie & Ellis with me to events in some situations). I do love being out at events and being in different lands, but my family comes first which is why I can see myself further dwindling down the amount of travelling I do each month.

A few highlights for me included having the honour of being invited to speak at jsconf.us. Another jsconf highlight was having my proposal for a talk on iframes being accepted by jsconf.eu. I (again) had the honour of speaking at the first jsconf.eu – and returning was an amazing experience where I tried very hard to attend as many talks as I could whilst still enjoying time chatting to friends, old and new.

All the other events were excellent, but one new event (to me) stood out that I whole heartedly recommend: From the Front. An Italian conference in the beautiful Bologna, very much at the indie end of the scale, but run with so much heart it was hard not to walk away wanting to start hacking on project and hug everyone around you.

Projects

The biggest project I worked on this year was the third iteration of JS Bin. The entire code base was converted from PHP to Node.js almost entirely to support the idea of “code casting” that I had back in 2008 when I first release JS Bin.

The biggest contribution to JS Bin 3 came from Aron Carroll – a talented developer based in Brighton who volunteered his time (for nearly 3 months) to write the new back end to JS Bin.

Now JS Bin includes (amongst others) code casting (where /watch is included on the url and viewer can see all your code as you code) and remote rendering.

Full Frontal 2012 was another huge success, and for me personally, the best year yet. We sold out in 2.5 hours this year – so there’s certainly demand to keep it going, and with discussion of demand over the years, this year I decided that I’d release video.

In the usual indie way, I decided to edit the videos myself which took at lot of time to start, but once in the rhythm wasn’t too bad. But for all my fighting with Final Cut Pro, I’m incredibly proud to have released the full conference freely on youtube.

There’s also a couple of projects that I’ve alluded to and not released properly yet (but I’ll get on to doing so in 2013): PhoneGapBin (which will be renamed) and my 365 canvas project – which creates a full canvas of images for print using JavaScript.

Personal

This year has been amazing watching Ellis grow and have his first birthday. Equally Tia’s second birthday was unexpectedly hard and she’s dearly missed by all.

I’ve been lucky enough to travel and see friends around the world and get up to all kinds of mischief (I’m looking at you Joe & Brian).

I consider myself lucky. I’m a man in my mid 30s and ordinarily not having chances to make new friendships in his later years, but the web industry has pushed me in to new places and forged brand new friendships out of nowhere. I’m hugely honoured, and consider this a big hug to tell you your friendship is appreciated.

When Ellis was born, I bought a Canon 550D and good lens (1.4 / 50mm) and continued our 365 project (a photo every day of the year) – and now I’ve got 3 years of photos to my name. My brother also asked me to photograph his wedding (although I’m still an amateur, I’m pretty proud of the job I did). Below is a canvas sample of my 2012 365 project (though we’re planning to print the full 3 years on a single canvas):

One final highlight for me was that .net interviewed me earlier on in the year. I remember back in 2007 thinking the .net magazine was a place I wanted to see my name printed. I’ve written articles for them in the past, but it was a nice little coup to be asked to be interviewed. The interview also includes a bit of back history and my approach to work – which was nice to share.

2013

What will it bring? Even more time with my family is most important to me – so staying near Julie & Ellis is my first priority.

I’d like to blog a little more often (somehow I’ve got about 4 blog posts halfway written – just need to finish them up).

I’ll continue my 365 project, but in 2013 I’m going to also start using my SLR for photos and try to experiment more (different angles, pin hole photograph, light painting and more).

I also have a few talks coming up where I’m trying to share something personal and how I use technology. So not a “new tech” talk so much, but trying to aim to inspire (I hope!).

Either way – happy new year – and I wish you all the success you deserve. See you soon dearest reader (unless it’s me reading, in which case, see you next time you’re near a mirror…).

Related posts:

1. My 2011
2. Ellis Tennyson Sharp
3. 2010: The Year I’ll Never Forget

Actually, truth be told, it’s not the entire workflow (I can’t create new files for instance) – but where I’m up to is: navigating my entire project, making changes and seeing the live impact of that change, testing new ideas and most importantly – actually saving those changes to disk without leaving DevTools.

Although I’m using Canary in the screencast, this functionality is available today in Chrome stable.

Saving

For a long while now, you could edit the “sources” to the web page, and hitting save cmd-s and it would update the current state of the JavaScript engine – which is powerful as hell alone.

But in a recent release to DevTools, a feature that previous required an extension, when you save, DevTools will ask you where you want to save the file to. In my case, I’m working on client side apps – which means just a static directory of JavaScript files. That means I can overwrite the existing file (js or css), and when I continue hitting save, it now overwrites that file on disk.

For me, this seemingly simple addition, means I can do a large amount of coding, testing and debugging directly inside the browser – which reduces the workflow loops.

It’s also worth adding that, whilst you haven’t refreshed, you can also get a complete list of all the modifications – right click on the source: local modifications. From there you can see the time of edits but also see diffs of those changes and revert them (though I believe you should be able to revert individual changes – i.e. just the first change through a patch, I didn’t have any success with this and suspect it’s just a bug in Chrome that I came across).

Code with live state

Another big win for me (which I didn’t include in the video) is that whilst I’m working inside the sources panel, and experiementing I can quickly and easily inspect the state of variables.

I’ll add a breakpoint, or a conditional breakpoint (right click on the line) – the code pauses, and hit esc to bring up a console and test code and check variable state or check entire lines of code to see if the result is what I’m expecting.

Space and stretching your legs

Finally, a couple of extra bits that make my workflow more comfortable for me. I always bump the font up on the DevTools (simple cmd-+) – maybe because I don’t like to strain my eyes, maybe because I’m getting old!

I dock DevTools to the right (in most cases) – which used to be under settings (the bottom right cog) but in Canary has moved to click-hold the bottom left “popout” icon.

Then lastly I tend to hide the source navigator (the list of files) and the debugger (the right hand side) using the little collapse icon.

What I’d like to see next

No doubt there’s someone I can direct these to, but equally I wanted to share my thoughts here because either maybe you know they’re coming, or there’s other features you’d like to see too:

• Ability to edit the “program” file, including the HTML, CSS & JavaScript #167289
• A comment toggle keyboard shortcut (I keep hitting what I think it is, and instead pausing code execution) #167284
• Much clearer feedback when saving wasn’t linked to a file on the hard disk (sometimes I’ve hit save and it’ll save in V8′s engine, but not actually to disk, because I hadn’t linked it up yet) #167285
• Autocomplete whilst editing source (perhaps looking up from the autocomplete in the console) #167290
• Toggle word wrap on sources #167287

I’m sure there’s more I’d like to see the more my workflow moves inside of DevTools. I certainly hope this is as useful to you as it was to me when I discovered “save as”!

Related posts:

1. My Workflow v2: Mobile, DevTools & LiveReload
2. JS Bin for Collaborative JavaScript Debugging
3. node.js rapid development: nodemon

Comments like these make me want to never contribute to this community.

via @adamyeates on Twitter

There was an article that upset a few (or one in particular) designer/UX/foo evanglists. I’m not pointing out this particular instance of pissing battles because if you’ve been on the web and following activitiy in the front end web community you’ve probably seen your fair share of pissing battles already.

And it’s not Adam in particular that I’m pointing out, but his sentiment (I’ve posted this with Adam’s permission first – I didn’t want to make it like I’m singling him out).

Adam, to me, is an excellent example of the newest generation of Web Worker. It’s possible you, ‘you’ reading this article, are also in that early stage in your career. Or you want become more involved like I did a few years back. Which is why this particular tweet has forced my fingertips to my keyboard to blog about this.

I’ve met my fair share of people who want to blog/get involved/speak (more or at all) but tell me that they don’t feel like they have anything to share. Or that there are smarter people out there – what could they possible contribute. But it’s Adam’s tweet is the last thing you want to see. What about all those people who think the same thing but don’t say it.

What I’d like to say to those of you thinking about contributing something-anything: do it. Blindly if needs be.

To me there’s two main types of blog posts: technical and opinion. Either one of these are good for you to start with. You’ve got opinions, right? You’ve solved a problem (either design based or with codey stuff).

You are unique. Your perspective is unique. Your solutions are unique.

Most bloggers I know – and certainly me included – started blogging because their memory is pretty useless. Google + blogging served as a search engine for their memory. Start there if you’re still not convinced.

If you share those, you will have helped someone, somewhere, sometime along their way. And the more of that we have, the better (even though it’s possible some content gets stale after a while).

As my friend Chris put it:

Most blog posts are crap, but even if a handful of people find them useful it’s worth it, no?

Hell. yes.

Related posts:

1. 8 questions after IE pissed the community off

The cliff notes

It’s 1 day, 3 teachers. You get to pick and choose 4 of the 6 topics. All designed around being a better front end developer giving you the core skills you need for project work.

Most importantly, the day is organised so you can choose any 4 topics and see them all – we’ve worked hard to make sure that’s possible. RequireJS, debugging, build and release processes, testing techniques, using git to its full advantage and Sass are all for the picking.

£220+VAT – sign up now! And if you think there should be more of these, let me know!

Planning the perfect day

What makes this day special is that you choose the content. So the day has been organised to allow for that, but the order of sessions is important to make sure you can get to them all. Below you can choose 4 topics (two in the morning, two in the afternoon), and the planner will show you what order you need to attend the sessions (and yes, this will be available on the day):

• Sass with Jake
• RequireJS with Rebecca
• Testing with Rebecca
• Git with Jake
• Debugging with Remy
• Build with Remy

There’s an interactive tool further down this page that will allow you try out different combinations.

Who are the trainers?

1. Myself, Remy Sharp
2. Rebecca Murphey who’s been doing loads of really great stuff in the developer tools arena, explaining what we should be using and why.
3. Jake Archibald who now works for Lanyrd and has loads of hands on experience with the problems developers face

Is there any more detail on what will each session will cover

A bit more, yes. Head over to 2012.full-frontal.org/workshop/tooling for full details.

How much, when and where?

£220+VAT (so £264), Wednesday 6th November 2012 at The Lighthouse in Brighton.

You can buy your ticket here

Is this suitable for beginners/intermediate/experts?

We’re shooting for these workshops to be ideally accessible for beginners and intermediate experienced developers. Obviously however if you’re an expert in Git, you’ll be able to miss that session and attend any of the other four sessions.

On top of which, there’ll be hands on exercises throughout the day, and practise makes perfect!

Why the mini sessions?

I felt like I needed to learn about Sass and RequireJS, but I knew that I needed more than a 45 minute conference session to get the taster I needed. Equally I didn’t want to spend £400 on a full day of Sass. What I really wanted was the taster but with hands on exercises as it’s the “fingers to keyboard” that helps my brain remember and really learn.

So why not create a mixed bag, interactive workshop where you get to have real hands on tasters. Not quite a full workshop where often there will be potions that I might know already, but where I get to decide the technologies I learn.

Do I need to decide which sessions I attend now?

No, but we will ask closer to the event which sessions you’re likely to attend so we can organise our schedule appropriately. One room holds 30 people, the others hold 16, so we’ll make sure the rooms are carefully balanced to demand.

Can I really attend any 4 sessions?

Yes. We’ve carefully planned the order of sessions so any combination of sessions is possible. Here’s a session planner (which you’ll have access to on the day too):

What if a session is full on the day?

If that’s the case, we’ll give you first priority when the session runs again. Make sure you prioritise the most important sessions you want for the morning (if possible).

Can I attend the same session twice?

If you so desire, absolutely.

Is there a question I haven’t answered?

If there is, just drop a comment and I’ll include the answer in this FAQ-type-blog post.

Related posts:

1. Full Frontal 2012 launches soon!
2. Creative HTML5 and JavaScript workshop by @seb_ly
3. My Big Workshop Tour

Full Frontal is launching tickets next Monday (25-June) at 10am, and I wanted to give you a heads up as to what you can expect.

I should add all this information will be fully revealed as soon as tickets go live next week.

Changes to the venue

No, we’re not moving from The Duke of Yorks just yet, but they will (in August) make the seats even more comfy, and bigger – but bigger means less – so this year, I’m afraid, there will be 15 people who can’t come to the event (as in there are 15 less seats!).

We are seriously looking in to whether we can video record the event and there’s a few logistical issues we need to overcome – but it is on our list of possible workarounds to the limit of number of people who can enjoy the event.

Until then, we will continue to capture the audio and release it for free.

Tickets and workshops

Tickets this year are £150+VAT (so £180 for those paying VAT), so if you need to provision the budget from a manager or some such, do that now because last year we sold out in 4 days and we’re hoping and bracing for the same.

Workshops

Some people didn’t realise, but our full day workshops (at £400+VAT) includes the conference day pass – so that’s two tickets for the price of one.

I’ll be running a mobile development workshop, the second will be on HTML5, the trainer will be announced on Monday.

We’re also running a special workshop-slash-tutorials day which I’m calling the “Tooling Tutorials Pick ‘n Mix”. The idea is there will be 3 trainers each teaching 2 hands on tutorials running for 90 minutes (git, testing, debugging, build processes, SASS and RequireJS). The day is carefully organised that you can attend any 4 sessions in the day (two in the morning, two in the afternoon).

The tutorials are designed to be more than just reading a blog post or watching a 40 minute talk, it goes that little bit further and gets your hands dirty and introduced to actually doing it. Note that this workshop doesn’t include a conference pass. The tickets also go on sale on Monday at £220+VAT.

I’m really excited about this pick ‘n mix workshop, the only disappointing thing is I won’t be able to attend them all because I’ll be running two of the six sessions.

Speakers

Speakers are important, but the way I curate Full Frontal is there is content I want to hear about, and I then try to find the best match to that content. We also have an open call for speakers where if you’re either proposing a talk I’ve suggested or you’re passionate about your subject, your talk will be considered for the event. Note that if you’ve attended the event in the past, you’ll notice a general lack of “library” based talks – this is on purpose and hints towards the kinds of talks I’d like to see at my event.

But you want to know who’s speaking, right?! The line up (so far) will be revealed on Monday at 10am :)

Get your mug in the background of our site

If you want your face to appear in the background of the site, or intend on coming (or “tracking”) add yourself to the Lanyrd page

Related posts:

1. Going Full Frontal in one week
2. Full Frontal JavaScript Conference
3. Win a ticket for the Full Frontal JavaScript Conference

What’s neat is I’ve got it to automatically pull the latest changes from github and automatically restart my Node process.

I don’t claim this to be particularly clever, and I’m sure I should be able to trigger a pull on the server as a push happens, but this works fairly well for my development workflow (where the app needs to be online) and is pretty simple – which I like.

Commands

For those like me who don’t care about the detail, here’s exactly what I’m doing in the terminal:

$ cd /WWW/jsbin/
$ screen -S gitpull
$ watch git pull
CTRL+a d
$ screen -S jsbin
$ nodemon .
CTRL+a d

Here’s what’s going on.

Screen

I’m using a linux process called screen which simply put: creates a persistent shell that you can send to the background and retrieve at a later date. This means I can run my processes inside a screen and get them back any time I want if there’s some debugging to do.

Now I’ve got a way of managing two tasks:

1. Pull from github for any changes
2. Restart my node process

Once you’re inside screen to detach (and return to your original shell) you use the command sequence CTRL+a d.

Here’s a few extra simple commands:

• screen -ls will show all the screen processes you’re running and the PIDs they have. You’ll need the PID to reattach the screen
• screen -r<PID> so in my case: screen -r gitpull will reattach and put me back in to the screen

Auto-updating code

Inside one screen we make use of watch which will keep running a process every 2 seconds. So I “watch” the git pull command.

Obviously this is a bit crap because it’s trying to pull from github to no avail most of the time, but it does mean that when I push new code up, this process will automatically pull.

Which leads me on to restarting…

Auto-reloading

In another screen I’m running the development tool Nodemon to auto restart when any JavaScript files change (which come from the git pull).

So that’s it. Pretty simple.

Related posts:

1. node.js rapid development: nodemon
2. Auto input grow with CSS (but is it a bug?)
3. How to setup your Mac web development environment

The word supported needs to be taken with a pinch of salt, because there’s all kinds of issues which I intend to show you in the following post.

Note that I have filed bugs for a number of these during the beta of iOS 5 – but god knows how the Radar Apple thing works, so I don’t know the issue numbers.

position:fixed, who cares?

I might have argued that fixed positioned doesn’t matter or isn’t really required in a good app. However, there’s an increasing number of iOS apps I’ve noticed that are actually just a collection of WebViews (mini-MobileSafaris) with fixed position toolbars as seen in Apple’s own AppStore app, the native Facebook app and Instagram below:

AppStore via @devongovett, Facebook via @9eggs

Issues

I’ve created a number of example pages that you can view for yourself, which are used in the following videos.

Juddering

If you add position:fixed in any normal way as you might on a “desktop” site, you’ll see some degree of juddering as the page scrolls.

Note that this is the simulator running, but I’ve also captured the real iPhone (using Reflection) showing the same behaviour.

The page used was: jsbin.com/3/ixewok/6/ (edit)

No updated values on scroll

The sharp eyed viewer might have spotted some values changing in the video. I’m monitoring the window.scrollTop and window.pageYOffset (and another value which we’ll look at later). You’ll notice that the values don’t change until the scroll has finished.

This is a problem if you want to monitor the page position to simulate effects like the bumping and shunting of category headings like you might see in the address book app.

Position drift

If the page is zoomed at all, which you can get in iOS when the user rotates from portrait to landscape, as the user scrolls in any scale beyond 1 (i.e. zoomed), the position fixed element drifts upwards (I’ve seen this drift entirely out of view before in other sites):

The page used was: jsbin.com/3/ixewok/6/ (edit)

Focus jumping

If there’s a focusable element inside the position fixed element, i.e. an input element, this can cause the entire fixed element to jump out of place. This will only happen if the user has scrolled any amount (but if you’re using position:fixed you’re expecting exactly that kind of usage).

The page used was: jsbin.com/3/ixewok/8/ (edit)

Scrolling == unusable position:fixed element

Corey Dutson pointed out there’s another issue with position fixed. Although his example show scrolling using JavaScript, the core problem is: if the page moves programatically (i.e. the user didn’t cause the scroll) the elements inside the fix element are unavailable.

From the screencast I’ve recorded you can see using iWebInspector that although MobileSafari has painted the fixed element in place, it’s actually not there – the actual element remains in place until you touch and move the page again.

The page used was: jsbin.com/3/ixewok/13/ (edit)

I don’t have a fix for this yet, and I suspect it’s a core painting issue inside of MobileSafari – but I will keep playing to see if there’s something that can be done.

Fixing juddering

With iOS 5, MobileSafari also came with -webkit-overflow-scrolling: touch. This is actually intended for inline blocks of content to the page (I mean inline with respect to the document).

If I change the CSS in my previous example, and set the height of my html, body and content block to 100%, then apply the scrolling touch property to the content, the juddering goes away. However, that alone does not fix the juddering.

The trick would seem to be: make sure your fixed position element is not on a “moving canvas”. This example has the fixed element over a scrolling element, but not inside of it.

So when I tried to apply this technique to the body element, the juddering was still visible, as the fixed element was inside the scrolling element.

I also captured this on the real device too.

The page used was: jsbin.com/3/ixewok/10/ (edit)

Getting scroll position to update

Again, those keen eyes might have spotted values are moving again. Note that as I’ve changed the CSS the body is no longer scrolling, so the 0 values on the left and right are window.scrollTop and window.pageYOffset respectively. Since the window isn’t scrolling, the content block is in an overflow, the values won’t change.

However, the content.scrollX value is changing – but it doesn’t by default.

Firstly, you have to attach any touch event handler to get this value to update as the user is scrolling (or actually touching), so in JavaScript I can add:

content.ontouchstart = function () {};

The touch event will work with start, end and move, and just needs a value set (note that I didn’t test just setting it to true – that might work too!).

However, it’s still not perfect. You’ll see from the video above, that it only updated whilst I’m touching. As soon as I let go during a swipe to scroll, the momentum makes the page continue to scroll, but the value doesn’t update.

I’ve yet to work out if it’s even possible to capture this value. ::sigh::

To conclude / TL;DR

Don’t use position:fixed inside a scrolling element, it’s juddery and looks rubbish (I’ve seen much worse than the juddering shown in the videos). Do make use of -webkit-overflow-scrolling: touch and if you want the scroll values, make sure you attach a touch handler to that scrolling element.

At the same time: make this work in other mobile browsers too – don’t just cater to Apple. It’s a huge headache that Apple have half arsed-ed-ly fixed the position:fixed issue and done in a typically Microsoft proprietory way.

Related posts:

1. How I Fixed WordPress’ Broken Upgrade
2. Element ‘in view’ Event Plugin
3. Fixing IE overflow problem

Web vs. Native – @mahemoff

“Will apps kill websites” – this month

• Facebook 2011 backing HTML5, whilst investing in native apps - instagram
• Instagram has no website (yet uses the web)
• Platforms, apps or otherwise, still using web infrastructure – via RESTful services
• Web – dev experience – boils down to view source + browser => already going
• UI capabilities still suck on the web – doing it consistently, with smooth effects is HARDDDD
• Offline doesn’t matter so much?
• Dev experience can be tricky for developers – maybe not the smoothest or more compatible tech. ie. the localStorage “issue”.
• Device integration is lacking – but will specs like WebRT solve this? Will Google resist these kinds of specs – why aren’t they leading this or is there a politic play whereby Chrome Book doesn’t require “apps”?

Were WebApps are lacking

• Single sign is hard
• Intention
• Device access
• Background processing…native apps are able to proactively schedule task in the background – web doesn’t have this at all yet (WebRT/thing?). Notifications / geo-fencing(?) / syncing. Background seems like one of the worst/highest level of requirements we need to compete web vs. native

The Challenge – what we need to do

• Advisory, like html5ple.se and some guidance – it’s kinda like the 90s again where there was a fuck load of JS libraries. Native has one way on the web, we have many ways and polyfills to get around issues.
• Web Apps should have support from the browser for single sign on – is this WebID (was BrowserID), etc?
• Developers need to contribute to “moving the web forward” – speak to the browser vendors. But isn’t part of the problem “Fucking Apple”, they don’t talk to anyone – nor do they release at any reasonable rate so developers
• Think about how web vs. native – web should remember your log in, application state – it shouldn’t appear to boot from scratch each time, but this is where we should be using localStorage, and back doesn’t destroy state!!! Ajax + history api.

Questions

• Is the point: browsers don’t matter – the web does…?
• Should the browser just be the webview?
• “You’re not on a fucking plane” – but then do all devs know how to build apps like gmail where it’s insanely quick because they know how to work the mobile device?
• AppCache is not a replicatement for localStorage – far from it.
• Is there a larger problem that the browser (and a pro) exposes data if the user wants to get to it. It makes SSO harder because of security, etc?
• Web vs. Native seems like two issues: browser and the web. Browsers being the limitation.

No app is an island – @paul_kinlan

Overview of some technology in browsers – “we’re moving faster than ever before”.

• CSS regions – makes print designers super happy – in that the reflow is correct.
• CSS filters – take that Instagram – using same technology as WebGL under the hood?
• Web Components – shadow DOM is the “component code”. Web Components do look really interesting because we’ve been re-writing components all the flipping time, but it seems to boil down to
• WebRTC – gives us the stream (though gUM is part of it), allows us to use a stream of video data (though god knows what format it’s in if we wanted to capture it…).
• And a fuck load more APIs: Gamepad API, battery, pointer lock, etc.

To the point: “tunnels and bridges”…All tunnel creation is bespoke (IRL), in that working across the web with things like oAuth is hard, and could well go horribly wrong.

Bridges are different: common patterns are part of the process.

Future of web app dev – is “client to client” – “bridging”.

Intents

• No oAuth – because you’re handing over?
• Integrating the “top 5″ APIs is hard, because a) they’re all fucking different, and b) what about when they shutdown (delicious), c) what about when you don’t integrate the users’ favourite service?
• Intents offers your list of services for the intent, user selects the service, and the service then returns the content in an open way - without the developer having to support all these services.
• Intent lets me send and receive => communication.
• Proposing an <intent> tag
• The content-type on the params determine the response kind, example: var params = { type: 'video/mp4', data: blob, transfer: [blob] };
• You can also establish communication channels (like P2P?) using Channel API and using ports.
• Can play today, Paul has written a polyfill with decent x-browser support (IE8 upwards).

Questions

• What about defaults? Chicken and egg – the user is new, do you offer default services? Is this even a problem?
• How do services register their action handlers?
• Really not keen on the action="http://webintents.org/share" – why the dependency?
• Doesn’t the startActivity/postResponse assume a persistent page or new tab or even background services? // No – it appears as just a popup, whilst my current page remains open.
• Are other browsers implementing Intents? Equally is Google starting to introduce it in their own apps, Google Drive for instance.

The web as it should be – @thebeebs

• Text Shadows weren’t fast enough for IE9 – the GPU was used for fonts, but the shadows were poorly performing (and equally on canvas – super poor performance even though it’s all hw accel).
• First half of talk: IE sucks – yep – MS know it. IE9 is supposed to be the new flagship. Honestly, still lacking, but IE10 is a good second step.
• 8 week launch cycles with previews. 12 weeks with IE10.
• Now collaborating (not more, but for a change).
• IE10 moving to “smallest chrome” – what about “Chromeless”?
• Ironically IE10 is touch, yet IE9 isn’t!!!
• Working on and contributing the CSS grid specification – combination of row/column. Are other browsers picking this up?
• IE10 is the delivery platform – within the browser and via the Metro application platform.
• IE10 appcache, data storage, etc. Basically where it should be.
• http://thebeebs.co.uk/prepare – compatibility indicator via a script include on your site – for debugging – things like userAgent sniffing, etc.

Questions

• When is IE10 going to be available on mobile?
• Once beyond the beta cycles, and in production ready, what about updates beyond that time? Do we have to wait another year?
• Is win.js implementing the standards – like File IO – is that going to use the standards, rather than the old school WSH type API – that’s utterly bespoke to Windows? The advantage of PhoneGap is that it relies on a standard, so ultimately, one day in the future, you can pull PhoneGap out and it should work. Can I pull out win.js and move to another platform?
• Touch – is this the standards based touch events?
• Debugging tools?
• Is IE10 the high street brand to the fashion industry? In that by the time IE10 comes out, Opera, FF and Chrome will be 12 months ahead. I guess this isn’t a problem – if IE supports “HTML5″ it means it’s serious business – I guess good for general web sites.
• Seriously – why can’t I install IE10 on my Mac directly? Or Linux? Sure, Apple don’t port Safari to Linux, and the Windows port is pretty horrible, but they’re arseholes anyway. // Response: No, they’re developing for their platform – to be fair – Apple to do the same.

Broken HTML5 promises – are we ‘appy? – @codepo8

• Apple is crippling the mobile browser. True, examples include WebGL, storage, audio, etc, etc, etc.
• Christian is asked at Mobile Congress is mostly around how do I protect my code, how does it compare to HTML5 – UX & performance.
• HTML5 has to be a marketing term – so it won’t ever be ready because it encompasses a mass of technology ranging from true HTML5 to CSS to Node.js!
• Tooling is lacking. Dreamweaver type tools, but all the way to Final Cut type tools – i.e. to compose amazing interactive sites. Current offerings: html.adobe.com and Sencha Architech…
• Christian successfully takes the piss out of @thebeebs and @mahemoff, who’s next?
• DRM is important to real companies. They have to protect their content.
• What about “native” performance? Zenga released a scroller library - and discussion said it works better if it was written for iOS only. Turned out that it was just the form value feedback that was slowing it down. (canvas scroller).
• Re: HTML5 is ready – did we pull it off? No, there’s more questions than answers right now. Those answers are hard (but isn’t a lot of this for the browsers to answer for us as developers?).
• Christian says we’re just keeping ourself busy with other things - like demoscene or abstractions or random arguments like the semi-colons (2nd reference – end on 3 pokes!). Why is Google and MS releasing demos the canvas demos, etc. (Surely they’re appealing to developers to get them on board).
• Talking about browsers stats. Me: honestly, these global stats don’t matter, the client user stats matter.
• Patents: even when we can simulate or re-create the effects but patents are killing innovation.

But “enough with the bitching”. Amen.

• Mozilla is a fully open organisation.
• “Kick ass” devtools. I hope he’s not referring to Firebug because I really don’t agree – the new devtools are a great step forward, but still way behind.
• MDN being supported not just by Mozilla – by people like Paul Irish from other browser vendors. An excellent web resource for teaching.
• More teaching from Mozilla and free access: mozparty, hack arcade, hackasourus, etc.
• Gladius – open source (on github) Mozilla supported game platform (that won’t be bought by another company and open!).
• C++ to JS conversion with Emscripten (WTF!?)
• Are we mobile yet – a visualisation of current state of mobile support, with direct links to the bugs – so go shake a stick to get them fixed.
• Contributing lots of new specifications: battery, camera, vibration, SMS sending – and all baked in to Boot 2 Gecko.
• Christian demos a B2G which appears fast. My own copy is slow, but I suspect the hardware is a huge factor.
• b2gbuilds.org for getting nightly builds. Nexus S, Galaxy SII and Galaxy Nexus flash image “coming soon”.
• Lots of events being run in Mozilla’s open space – also open for drop in working.
• Wants people to make things that work.

Questions

• Why is UX coming up? Surely the OS should provide the UX for these elements, buttons, etc.

Related posts:

1. jQuery API Browser

I read through, and here’s my take and criticism.

The reporting on the BBC site is excellent, or excellent to me because it’s a digested form of the original report and begins with this quote:

We hope this paper demonstrates the importance of building a mobile site optimised for mobile devices.

“Perfect!” – I exclaim to myself. But go ahead and try reading the report. It may be clear to a hardened engineer, but I’m be prepared to be 9 out of 10† web workers (web developers and designers all under one cosy roof) would a) not follow the report, and b) likely not make it to the end of the report. It’s not written for them – or rather it’s undigested.

† I’d actually wager more than 9/10ths, but it’s a catchier term!

The BBC article does pick up on two messages, one that’s a pretty nice take away (and frankly, I managed to glean this from the article too):

…using the .jpeg image format instead of other file types like .gif and .png

This appeared to save on battery. If only we had the flipping connection type API in more browsers we could use media queries to fix this elegantly.

What’s interesting is (unsurprisingly) Gmail comes up trumps on performance (in the non-eating battery performance metric) but what’s more interesting is the reasons “why”. The paper claims:

Gmail, the most “green” mobile site we found, uses HTML links to open email messages that the user clicks on. [...] Our experiments suggest that using links instead of Javascript greatly reduces the rendering energy for the page. Thus, by designing the mobile version of the site differently than its desktop version, Gmail was able to save energy on the phone.

This is really interesting to me because I’ve spent some time picking apart how Gmail works (and I’m far from done), but I was pretty damn sure that JavaScript features fairly heavily, including clicking email messages. So I fired up my Android, opened Chrome, opened the remote debugging port and sniffed around the DOM (as usual) and here’s what a message (that you tap/click/whatever) looks like:

The first highlighted onclick is to star the email, the second for selecting it for some group action, and the third, yes, that div element, that has a click handler on it to open the message. Not “using HTML links to open email messages”. Just to drum the point home – do you notice even one single HTML (anchor) link in there?

I think perhaps what Gmail are doing to save on battery is deferring the bulk of the JavaScript using the evil eval technique where they’re deploying script modules in commented out code, and eval’ing it in to execution on demand, both reducing the initial JavaScript parsing, but also negates the need for extra (expensive) HTTP requests for JavaScript modules. Something I suspect, based on this paper, Wikipedia could do with looking at (since it has the highest JavaScript execution time, yet it’s the most content-ty web site I know of!).

Not to be ignored

The BBC article does conclude with:

The research is to be presented at the World Wide Web 2012 conference in Lyon this week.

I wonder if/hope there’ll be videos of these talks, as the paper in it’s current state is likely to be overlooked by a lot of our peers (understandably) but it does have an important message as smartphones become more capable (with JavaScript APIs like WebGL and the like): with great power comes great responsibility.

…technically, if the phone had great power, I guess the responsibility would go out the window because then you could go wild, but you get my gist – be wary this isn’t a constantly powered device like a desktop computer. Most of us know how crap mobile phone batteries can be.

I’m just looking forward to web friendly interpretation of these and future results.

Related posts:

1. Performance profiling JavaScript
2. My Workflow v2: Mobile, DevTools & LiveReload
3. T-Mobile allow free Wifi Google Maps

Workshops

Workshops over the last 12 months have really increased for me – both in public workshops (often via events) and private company workshops. I’ve now finally got so much HTML5 content that companies can now create a “pick and mix” HTML5 workshop spanning over anything from 1 to 4 days.

I’m up in Manchester next week doing private workshops for the BBC on mobile web dev. Possibly my favourite quote from the last time I ran this event was from James O’Brien aka @sparrk:

Remy’s HTML5 for mobile workshop showed me how to do at least three things I’d previously thought were impossible.

There’s a few public workshops you can attend, starting with:

• Mobile HTML5 Web Apps – Amsterdam €350
• 3 workshops: HTML5, Mobile and Node – you’ll have to pick me out in the table, based in London though

I’ll also be releasing a new workshop for Full Frontal – so keep an eye out for that :)

Talks

• SourceDevCon – talking about using Node to go real-time (with a healthy dash of HTML5)
• Mobilism – on debugging mobile devices and the pain and some technique (also 10% discount off regular ticket price (whilst stocks last!))
• Future of Web Design – on how developers and designers can work better together (or at least from my perspective!)
• Reasons to be “Appy” – mobile debugging again – this time in London (a small conference with only 250 places)
• NDC 2012 – on the lesser known (or used) technologies in and around HTML5 that I think should be worthy of your attention
• From the Front – the same HTML5 talk, but this time in Italy (early bird tickets still on sale until end of April)

I’m sure more talks will turn crop up and there’s a talk in me that I want to give about what I’ve learnt in developing JSBin over the last 4 years.

If you want me to talk…

Do get in touch (via my company site) if you’ve got an event and want to hear one of these talks, or equally if you company would like some in-house training.

Otherwise, I look forward to seeing and meeting some of you at the upcoming events!

Related posts:

1. Full Frontal 2012 launches soon!
2. My Big Workshop Tour
3. Feed of Events via Microformats

1. Browser vendors for Firefox, Opera and IE will eventually implement -webkit- prefixes (a subset). Sad, but true. It’s an amazingly bad idea, and I’d love to be wrong, but browsers are like bulldozers, they’ll go where they want and more importantly: need to go.
2. Vendor prefixes are a good thing. Or rather experimental prefixes are a good thing. They allow developers to test and feed back to vendors.
3. Vendor prefixes should be dropped from production level browsers and only made available in beta browser versions.
4. Point above will not happen (or at least in the short term). Google and Apple have said as much. This was the same reasons Microsoft gave: they didn’t want to break the web. Microsoft did eventually drop propitiatory tech like CSS filters (well, it vendor-prefixed it, but the effect non-prefixed is “broken” in IE9), so maybe in the future this may happen.
5. Maybe the middle ground is we draw a line in the sand, and say: All current prefixes will remain as they are (WRT production browsers). All new experimental properties will have a finite lifetime, and not make it to production.
6. Yep, the working group should move faster to retire beta technology (if it works), but this hasn’t happened any time soon (see the irony?!).
7. Do not go duplicating every -webkit- prefix you find: they’re not all supported, nor are all the values always the same. Use your head, obviously! This needs to be done on a case-by-case basis. ie. Add -moz- et al for -webkit-border-radius but when you encounter linear gradients the syntax is different.
8. Do check your code against tools like csslint – it will tell you which vendor-prefixes can be reused today. I’m close to having a tool ready that will automatically fix these for you – but to be clear: this will only stem the flow of the wound, and doesn’t fix it ultimately for the future.
9. Should all browsers use the WebKit render engine? Hell no. WebKit would continue to innovate until it was finished, then we’d have that really long quiet period that Microsoft demonstrated with IE6, where expectations move on but browsers don’t. No, this a stupid suggestion.
10. Don’t stop evangelising. It’s a slow slog and is never a completed job.

Related posts:

1. Vendor Prefixes – about to go south

This is bat shit crazy, but where the web has arrived to. This is one developer’s opinion, but you need to voice your opinion now, and if you’re in agreement that this is madness, you need to act now. Make your voice heard, blog about it, tweet about it: make a lot of noise.

How is this a problem?

The CSS working group met very recently and openly talked about whether they should implement `-webkit` as part of the CSS specification in Firefox. This means other browser such as Opera and Internet Explorer could and would also implement these prefixes which would result in your site working™ in their browser.

Tantek led the conversation with:

tantek: At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla

plinss: Zero.

tantek: Currently we have zero. Zero is no longer an option for us.

The fear the browsers have, understandably, is that developers are coding for webkit prefixes in their CSS because they’re only targetting webkit based browsers.

Now that -webkit prefixes are so prolific in the wild (not my statement, but as suggested from the meeting minute notes), it seems the approach most want in the CSS working group is to simply implement the non-standard feature in to their specification. An oversimplification, but worryingly true.

There is some voice of sanity, namely in Daniel Glazman / glazou and Peter Linss.

You have to still appreciate the politics of the problem:

tantek: What are the thresholds, even approximate, for implementing -webkit- properites (or none)?

glazou: Unbelieveable we are having this discussion.

Florian: Our job is to solve interoperability. We want to discuss it here, because that’s our job.

tantek: Help us minimize the damage.

They’re trying to get interoperability: a good thing. But implementing other vendor prefixes in a browser is not the way to go about it.

On minimising the damage

Minimising the impact of this change is a misnomer. This is pandora’s box, no matter how you look at it. Once you add a single -webkit vendor prefix the expectation of the developer changes. If you can use a -webkit prefix in Firefox for gradients or transforms (for example), why can’t I use it for other things like CSS masks. And then other things.

If developers are lazy today (and we are – it’s what makes us fast and good), by adding -webkit prefixes to other browsers it’ll allow us to be even lazier, and by adding -webkit to the spec, the CSS working group will have set the precedence that we can, as developers, put any prefixes property in the other browsers.

At which point: webkit won the browser game and all other browsers should retire.

The only sensible step after implementing WebKit’s experimental properties is to simply adopt the entire render engine. A silly analogy, but you can see how you could get there.

The working groups are there to give us specs on how to do things the right way:

glazou: I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.

And then its affect on JavaScript

What concerns me even more is this:

glazou: I think it’s very unfortunate timing, esp. now that we’re trying to use prefixes for JS APIs.

We’re already starting to see things like MozWebSocket and the like. The only saving grace we have is adopting polyfill techniques – but ensuring we code against the right specification, and not vendor prefixed APIs.

I may be wrong, but I feel like the evangelism is strong in this area, and developers are keen to avoid prefixes – and there’s enough libraries that takes this problem away from devs.

CSS hasn’t been so lucky.

Who’s guilty?

Apple and Chrome: They’re supporting vendor prefixed properties like they’re a standard part of development.

Firefox, Opera and Internet Explorer: They should have been on the ball more. Need to push their evangelism further. Teach developers that it’s not exclusively -webkit to style elements.

All the browsers: experimental suggests that it will either be discarded or implemented fully at some point. It’s both not clear what’s a real specification be experimentally supported, nor when those experimental prefixes will be dropped.

The working group: for not getting these properties to standards quickly enough. The web moves quickly, and as much as a I appreciate that the standards will not move as quickly, they’re still taking way too long.

Evangelists: We’re too eager to show off experimental effects. They’re cool, right? But it’s cost us, and we should always used vendor prefixes as a backup, not as the final thing.

Developers: We know better. We know/hope that eventually these prefixes will be dropped, but we’re propagating this problem.

You and me: I’m just as guilty as everyone else in using WebKit only prefixes.

How I’ve been guilty and why

1. I don’t know which browsers support which prefixes or values for that matter. Firefox never seemed to have interoperability with CSS gradients or transforms which made it hard to know what would work.
2. I honestly can’t tell what’s a real property from the CSS specs compared to something made up by the vendor (from what I can tell webkit-text-size-adjust is one of those examples)
3. I have absolutely no clue when the prefix will be dropped. Firefox held on to the -moz-opacity for a looooonnng time. This is my expectation for the other prefixed properties I use today.

What can we do instead?

This is the question that they group should be asking.

There’s things we can do as developers and evangelists, and there’s things the browsers must do.

As developers we need to better educate. It worked with moving to standards away from spaghetti code back in the height of XHTML-esque coding, it can work again.

We need tools to make it easier not to propagate this problem. Tools like csslint and -prefix-free are a start. I’m about to embark on a tool that will plug all the missing vendor prefixes too (not a JS solution like Lea’s tool, but a standalone service – help me if you can/want).

Browsers need to:

1. 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.
2. Drop experimental prefixes – not entirely, but after a finite amount of time. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.
3. Work with the working groups (…Apple).

And more. Blog about it. Tweet about it. Make some noise. If this happens, the working group will have failed. I’ll leave you with this:

plinss: If we go down this path we have broken standardization.

Updates and further reading

• Nate Vaughn / @folktrash on vendor prefixes – a good round up
• PPK’s take – though I don’t entirely agree with all his points, still important reading
• Fellow author, Bruce Lawson
• Follow up interview with Tantek by Eric Meyer
• The Might Alex Russell’s step back, take it all in, uber post

Related posts:

1. The TL;DR vendor-prefix post
2. Broken Offline Support
3. Safari 3.1 web developer functionality

In short, this year has still been hard after losing Tia in August 2010 but as painful as that is, happiness arrived as a bundle we decided to call Ellis Tennyson Sharp. Pretty much everything else falls away compared to family, as much as I love my work, I hope it will remain a distant second to those most important around me.

Professional

On that note though, I’ll start with what I’ve been up to in the web world.

Speaking

I was again fortunate enough to be invited to speak at a real variety of conferences – some micro events like Aral’s Geek Ninja to larger events like OSCON.

I was also asked back to Flash on the Beach (I had to pull out last year) which was a real pleasure. The event is run in Brighton, and John Davey is possibly one of the nicest people I know (whom I’m convinced is actually just a British John Wayne). For a conference that has a strong Flash following the audience were particularly welcoming, and even sang me happy birthday!

Personally however, my favourite conference of 2011 was Highland Fling. It was organised and run in the same spirit as Full Frontal which left me excited and inspired. I’m a big fan of the indie events and if the organiser is full of passion it stands to reason that it just oozes out in to the day. Highly recommend, and if it’s on again in 2012, it’s a damn fine excuse to visit Scotland again.

Photo by Drew McLellan

Workshops

I’d been considering whether I could pull off a “workshop tour” towards the end of 2010, and early on in the year, Julie helped me pull it off. We ran six workshops in five cities over two weeks: Brighton, Manchester, Bristol, London and Nottingham. Amazingly the project was a success both from the teaching, but the business side too. There’s a lot of risk involved in trying to sell multiple workshops at once but in the last weeks leading up to the workshops, they managed to sell out.

I also ran my first two-dayer on Node for Full Frontal – something I’ll be running again a few times this year, so if you’re interested in be notified, drop me a message.

Projects

When I list out these projects that I’ve released, more often than not I think: damn, I wish I’d done more. But on the other hand, I could have done a lot less – or kept them to myself. So hopefully these are useful to someone as well as me!

• Inliner – a tool to “inline the crap” out of web sites, inlining CSS, images, fonts and JavaScript, compressing as much as possible. Also available as a command line tool.
• responsivepx – a tool for testing and finding breaking points in responsive design.
• Introducing HTML5 2nd Edition – somehow Bruce and I managed to pull off a 2nd edition, packed with new info and even a new chapter on polyfills.
• mit-license – a public resource to host your own MIT-License under your own name, eg. rem.mit-license.org (more)
• jsconsole remote support – I got fed up with the insane debugging techniques and poor console support in mobile smart phones – so I tweaked jsconsole so it could do exactly that!
• Full Frontal 2011 – another year and (if I don’t say so myself) a another huge success. It was an amazing day and to my surprise folks were even telling me that it was the best year yet. So, no pressure for 2012!

Randomly aside, I was nominated to have my face happy-webbie-fied amongst 60-odd others. Somehow in the voting rounds it end up me, so the kind folks at nGen Works have now immortalised me as a cartoon character – very neat :)

Personal

The year was still hard after losing Tia last year. Julie and I decided early that we still wanted to continue with our family, and the new year we would try for our second. Ellis was conceived much quicker than either of us hoped – one of the many blessings we had with Smudge’s pregnancy (as we saw Ellis in a 7 week scan, his nickname came from what he resembled most: a smudge!).

Julie delivered Ellis Tennyson Sharp on 29-September 2011 at 11:14am – safely and happily into the arms of his parents. An absolutely amazing day. As tough as it’s been, both a mix of emotions as we never had this with Tia, but also the physical side of things, like dealing with an upset human being whose communication skills are rather limited. As tough as that’s been, Ellis is so insanely cute that what he cracks a smile all the stresses are forgotten and I can’t help but be amazed.

Just a month before Ellis was born was Tia’s first birthday. In the year leading up to that date we started a local project in her name to improve a local children’s park. We’ve raised a little over £3,000 for the project and there’s more we want to do to improve the area for children (though half the money raised goes to SANDS – a charity for bereaved parents). I also had Tia’s hand print tattooed on to me permanently so I can always keep her near.

Both Julie and I celebrated 15 years of being together and completed our second year of 365 project – which our plan is to create a single canvas print with two years of 365 picture – so that should be epic!

Utterly unrelated, but I built a Death Star this Christmas too – too cool not to include in my round up – definitely going to be doing more Lego next year!

2012?

I’m hoping to build my business up. I always wanted to grow my little agency to around 6 people. Obviously I need the business in place before I go along employing people, so if there’s some JavaScript (both client and server side) project that you need an A-team on the case – do get in touch!

Otherwise, I’m hoping do more of the same, more blogging, more project, continue with our 365 – but more importantly: spend as much time as I can with my family.

Here’s to 2012, cheers!

Related posts:

1. Ellis Tennyson Sharp
2. My 2012
3. 2010: The Year I’ll Never Forget