My Dad is Missing
I don’t usually use this space for personal musings, but this is an important one to me. My Dad has been missing for a month now, leaving his house in Surrey on April 2nd, and his car was found in Cornwall one week later, although it could’ve been there since the day he left.
Realistically, he could be anywhere by now and we know nothing of his whereabouts or intentions. Please help us spread the word and get his face known to as many people as possible by sharing the link below on your social networks of choice.
http://johnbarnettmissing.tumblr.com
Your support is greatly appreciated.
The past couple of months have been pretty intense and fast paced: a project that consisted of two interaction designers, two visual designers and three developers. A small and easy to overlook feature in the Web Inspector has actually had a noticeable impact in the way we’ve worked.
Saving out the CSS straight from the browser; its a bit like using a WYSIWYG editor that isn’t awful.
Its as quick as editing the styles in the Elements tab as I’m sure you do a hundred times a day already, jumping over to the Resources, selecting that stylesheet and hitting Save As in the contextual menu.


Its not that I don’t care about fonts and things…
We all want our work to look its best.
If you work in an agency, you probably work with designers and people who are passionate about typography, layout, colours, and so on. Really, this means you work with people who care about CSS (albeit sometimes indirectly).
I’ve worked on many projects where I’ve seen two people, typically the person in charge of typography, and a front-end developer spending hours in the Web Inspector nudging up and down the line-height values.
My experience is that any web designer worth their salt doesn’t mind taking a few hours to learn the basics of CSS. I’m not suggesting we ask everyone to know about zoom:1, but if the people who make the typography styles can actually adjust the leading, kerning and sizing styles as they will be seen, then this is a good thing.
Teaching your design team the whole ‘Right click, Inspect Element’ thing and perhaps some of the styles below, and then asking them to save out their changes and send them straight to you for merging in can save impressive amounts of time.
font-sizefont-familyfont-weightletter-spacingline-heightmargin/paddingtext-transformcolor-webkit-font-smoothing ??
Not only does it let you get on with what you’ve got to do, but it allows the people who are in charge of the typography to work on it as and when they want. And thanks to this little feature, they can send you the actual code rather than an updated PSD document.
I’ve considered separating typography styles into its own stylesheet to make the merge process a cleaner one, but I’m sure the basics are there.
I like.
Using HTML5 Canvas for Image Masks
Recently I’ve found myself referring to Jake‘s (the bastard legend that is) HTML5 Video with alpha transparency demo for reference into some pixel manipulation techniques with Canvas. Used in a slightly different context, but largely the same technique, we can use Canvas to apply a full alpha mask to any image element.
For Webkit browsers, a similar effect can be used with CSS Masks, but perhaps you need slightly wider browser support, or you want to use the masked image in Canvas somewhere else.
This function is just a base and should really be tailored to your use case, but it shows how easy it is to read the alpha data from one image, and apply it to another. Using getImageData, a 4-chunk CanvasPixelArray is returned with each pixels’ R, G, B, and A values. The result is achieved reading and ‘merging’ the RGB values from the base image, and the A values from the mask.
That’s all it does, but having it wrapped up into a single function is sometimes easier to work with (again, depending on your use case). The function creates a couple of Canvas elements on the DOM and uses them to mash the pixels together. You just pass in the base and mask images, and get back the single masked image either as a CanvasPixelArray, or as a Base-64 encoded data URL.
To give you an idea of what the images can be, here are the raw images I’m using for the utterly useless demo.
- Base JPEG: http://playground.benbarnett.net/canvas-mask/img/octagon.jpg
- Mask PNG-24: http://playground.benbarnett.net/canvas-mask/img/alpha.png
Feel free to head over to the Github repo for further docs.
Just wrote a little plugin whilst working on a project because I keep finding myself using this functionality and having to write a handler in my application code. This plugin can be dropped in, just like jQuery Animate Enhanced and weighs in at less than 1KB, and it will enable you to quickly grab a partial or fragment of the AJAX endpoint.
Here’s some dummy code:
There’s not really much more I can say about this. Its unobtrusive, light weight and will simply hand over to the native jQuery.get() method if no selector is supplied.
Further Resources
Where we are now
So it seems that the YouTube Player API doesn’t offer any support for the HTML5 video player, while the standard Embed code does. It kinds of makes sense with the way they’ve implemented their player API as ultimately it’s just embedding a SWF with a few paramaters, but its still annoying. Its clear that the major players are working towards something, but for now we’re left with finding our own way through.
The reason its annoying is that the only way to truly skin the YouTube player (without its hideous & pointless background colour customization) is to use the Chromeless player and then overlay your own controls. This is relatively easy to do, and a there’s a reasonable demonstration on the YouTube Player Demo page.
What’s the point?
The point is so that you can have a custom YouTube player, and have it work on mobile devices without Flash. It also means that you get the benefits of YouTube’s encoding lair and that the number of ‘Views’ will be counted both on YouTube and from your site.
Making it work
As we need SWFObject on the page in order to embed the Chromeless player for our custom skin, we can use a handy method in its API:
swfobject.hasFlashPlayerVersion(versionStr) // e.g. "8.0.0"
With that, we can do a simple if statement, and hand the logic back to the standard YouTube embed code should that function return false. We do this because the basic embed code will use the HTML5 player where it can, giving us native iPad/iPhone/iWhatever support. You can grab this simply by going to YouTube, clicking Embed, and copying the code it gives you.
Either way, we palm off to YouTube at this point, allowing them to make the correct decision in a non-Flash environment, the logic behind which will probably change quite regularly.
Note: it’s not possible to skin the HTML5 Video Player on Mobile Safari, because it uses the native video player. Not a biggie though, it looks awesome.
Here’s a basic code example:
Demo
This is ugly, rudimentary and not for production. But it demonstrates the technique. Try the link below out on any browser, and on an iPad/iPhone:
http://clients.brushfiredesign.net/playground/youtube/youtube.html
You’ll see that with some basic styling, you can fairly easily create a completely custom player design using the elements on that page, which also works on your iPad.
Dead easy but cute little technique this one. I’m working with a design that had an overlay effect over some of the text based headings.
The way I’ve seen it done before (and I have in fact done it myself) is to simply stick a PNG with alpha transparency on top of the text in question. Granted, this technique does work but it felt like a bit of a cludge. It also means you can’t highlight the text underneath it. Annoying and bad for usability.
I then cast my mind back to the stunning Kaleidoscope App website. Using a Webkit browser, look closely at the colour wheel triangle thingy and you’ll notice it’s spinning. Dig deeper in the CSS and you’ll see they’re using a really nice masking technique to achieve that.
Simple enough, but I wanted this effect to appear on all browsers rather than just Webkit.
Detecting Webkit Masking Support
Feature detection is the best way to implement this technique. Rather than just seeing if “browser = Chrome or Webkit”, you can either use the Modernizr library to do this for you, or simply grab the following line of Javascript and insert it above your CSS.
document.documentElement.className = document.documentElement.style.WebkitMask!==undefined?"masking":"nomasking";
That will add a class of ‘masking’ to your HTML tag should the feature be supported. And, by including this pre-CSS, you’ll get no flickering of content. You can then just add the .masking prefix to styles that use it.
Creating the Mask
Basic Photoshop skills should be enough to create pretty much any type of mask. The key point to remember is that they’re unlike Photoshop masks in that they rely on Alpha transparency rather than black or white.
Webkit masks require a PNG with an alpha channel, i.e. a 24 or 32 bit PNG.
Areas of the mask with 0% opacity will hide that section of the element the mask is being applied to. Areas with 100% will render as usual. Then, as you’d expect, you can use anything in-between for partial transparency.
Here’s the mask I’m using. I’ve dropped it in a green container so you can see where the transparency lies.

The CSS
This is the easy bit. For non ‘.masking’ browsers, implement the same ‘overlay’ technique as you’ve no doubt done before.
For browsers that do support Webkit Masking, just override the element (for example, an h1 tag) to set it.
.masking h1 { -webkit-mask-image: url(../img/bg/text-effect-mask.png); }
You can then play with the positioning and things should you need to;
- -webkit-mask-position-y
- -webkit-mask-position-x
- -webkit-mask-repeat
Here’s a screenshot of the output.
A nice, selectable, accessible, progressively enhanced text overlay effect.
Simple right?
This is a rudimentary use of the Webkit mask. As you can see from the Made by Sofa guys (creators of Kaleidoscope App), you can create some amazing effects and choose either to implement a technique for non-supporting browsers, or just degrade gracefully to a static version, as they’ve done.
You can also use them on pretty much any DOM element there is, as the comments on the Surfin’ Safari docs explain.
On a client project recently, we’ve been working with some heavy full page transitions, which can look extra lovely when on hardware accelerated browsers and devices. I was struggling to find a neat way to write the front-end code, which is using jQuery, to degrade and enhance itself automatically without putting switch statements and creating multiple stylesheets all over the place.
This is where my jquery-animate-enhanced plugin comes in. The idea was to have a one hundred percent seamless integration, and backwards compatibility with older browsers. For this reason, it just extends $.animate() which we all know and love and detects if you’re trying to animate something that would be better off done with a CSS3 transition. Absolutely zero effort required.
The plugin.
Extend $.animate() to detect CSS transitions for Webkit, Mozilla and Opera and convert animations automatically. Compatible with IE6+
Properties supported: (more to come)
- left : using translate(x, y) or translate3d(x, y, z)
- top : using translate(x, y) or translate3d(x, y, z)
- opacity
Note that any properties not mentioned above will simply be handled by the standard jQuery $.animate() method. This plugin adds new functionality without taking any away.
Demo
Check out a working demo on the plugin’s homepage.
What it does
The plugin will analyse the properties you’re animating on, and select the most appropriate method for the browser in use. This means your transitions on left, top and opacity will convert to a CSS3 transition on Webkit & Mozilla agents that support it, and Opera 10.50+. If the user is on a browser that has no CSS3 transitions, this plugin knows about it and won’t get involved. Silent degradation
Multiple callback mechanisms are created internally to monitor for DOM manipulation and for all ‘transitionend‘ CSS3 events to be picked up. This means you have one neat callback() for the whole animation regardless on whether the plugin is using CSS3, DOM, or both for its animations.
Progressively enhanced CSS3 animations without having to do any browser detection or special CSS, therefore using the same Javascript across your applications and websites.
As this plugin uses CSS3 translate where available, there is an internal callback mechanism to reset the ‘left’ and/or ‘top’ properties so that your layout is unaffected.
Usage
Usage is identical to the jQuery animate() function, but it comes with 3 new paramaters, which are totally optional and safe to leave untouched for general use:
- avoidTransforms: (Boolean)By default the plugin will convert left and top animations to the CSS3 style -webkit-transform (or equivalent) to aid hardware acceleration. This functionality can be disabled by setting this to true.
- useTranslate3d: (Boolean)By default the plugin will use 2d translations due to wider browser support. Set this to true to use translate3d instead. Recommended for iPhone/iPad development (here’s why).
- leaveTransforms: (Boolean)By default if the plugin is animating a left or a top property, the translate (2d or 3d depending on setting above) CSS3 transformation will be used. To preserve other layout dependencies, once the transition is complete, these transitions are removed and converted back to the real left and top values. Set this to true to skip this functionality.
Give it a go
More information is available either on the GitHub repository, or on the plugin homepage. Thoughts very much welcome.
The answer is “kind of”.
I’m a believer of the “write once, deploy anywhere” attitude. I’m also a big fan of things like WhitherApps; James has done a great job taking the (native) BBC News app and rebuilding it using just HTML and CSS to prove out this very concept.
BUT… people would be lying if they told you it’s exactly the same as writing CSS for desktop browsers. It just isn’t.
No support for the CSS fixed position
You could be forgiven for thinking that it just reverts back to absolute positioning like it does in IE6, but in fact it is not same as explicitly setting an element to absolute. The behaviour is subtly different, and I found that running any CSS3 style webkit transitions were much more performant, and less ‘flickery’ on an element with fixed position, over one with absolute even though the layout was identical.
Very strange considering there’s no support for fixed position. Couldn’t find that one in the specs anywhere either, so I remain baffled. My solution was to try both position attributes and see which performs better.
Usually though, Cubiq’s iScroll will do the trick as it’s more than likely the reason for needing fixed positioning anyway. That plugin genuinely works well by the way. Use it.
Hardware accelerated CSS transformations… but are they, really?
This one took me a good few hours to work out when I could have been quite happily doing far more productive things with my day. I knew already that the ‘-webkit-transform’ and ‘opacity’ attributes were hardware accelerated for webkit transitions. If you’re experiencing a flicker with css3 transitions, this is how to fix it.
It is true that opacity is hardware accelerated. It is also true that -webkit-transform is hardware accelerated, but, if you’re using translateX, translateY or translateZ, you don’t get that luxury. Take a typical CSS transition;
#element {
-webkit-transition: -webkit-transform 1s linear;
-webkit-transform: translateX(0);
}
#element.transformed {
-webkit-transform: translateX(300px);
}
In any webkit browser, you’ll get whatever #element is to move 300 pixels to the right, in a linear 1 second animation. On Mobile Safari, it will likely ‘flicker’ before/during/after the transition. The key is to use translate3d(x, y, z). The simple change shown below makes all the difference.
#element.transformed {
-webkit-transform: translate3d(300px, 0, 0);
}
It’s ridiculously simple, but honestly why would that be hardware accelerated and not the shorter hand, translateX property?
Avoid Javascript Libraries
You’ll notice that the Javascript engine on the iPhone is incredibly slow. The iPad is greatly improved but its still advisable to minimise Javascript, particularly for things like animations. Always use a translate transition over animating the left or top properties. The CSS3 transitions are perfectly smooth and look great. Arguably you don’t need jQuery for mobile apps as a lot of ‘weight’ comes from dealing with cross browser differences; obviously not being an issue if we’re focussing solely on mobile webkit. With the new CSS selector engine, document.querySelectorAll(); you still get lightening fast ‘jQuery style’ DOM selections. Time to brush off the raw Javascript skills (or just be lazy and wait for jQuery mobile).
Am I being impatient?
There’s only a handful of cases that have proved to be quite time consuming during development, but the point here is a bigger one.
The whole idea of unifying standards across all devices is the way forward. The thing is though that I can’t help feeling that we’re harking back to the “Are you using Netscape or Internet Explorer?” days. I wish we didn’t have to know about these tricks. It means that without position fixed, we need to use (and write) Javascript extensions to help us out, but then we add weight and potential bugs to the desktop side of things. Do we really have to start detecting whether we’re on an iPad and serve up specialised code? What about sites that we wrote before all this came about?
I’m still behind the idea of using HTML powered apps with simple Objective-C wrappers to encase everything into a native application. With a bit of reading up, and more than one or two stabs in the dark, its definitely not impossible to make an HTML driven app “feel” just as native as any other.
I guess one just has to accept that the concept of using exactly the same code on mobile and desktop devices still isn’t quite there.
The London Tube Map is a wonderful thing. Making it interactive makes it even more wonderful. The possibilities of what can be done with a fully interactive, SVG (well, RaphaelJS) driven tube map in terms of visualisations are endless. Given that TFL have also made a giant leap towards opening their data, which in itself has sewed the seeds from some pretty exciting projects already; combining the two could be a lot of fun.
Is there an easy way to convert this increasingly mammoth tube map into a clean, cross browser, interactive map?

The short answer is…. no, but here’s how anyway.
Allow me to explain why. I’m sure someone will find this post and tell me straight away that I could’ve done this using a much simpler approach, but this is how I tackled it.
Firstly, get the right Tube Map
Ok, it sounds obvious but this is quite important as it can drastically affect how much work we have to do. I’m not implying that I downloaded the map for New York Metro, but the starting format for this key.
The first part is that we need a vector based tube map, i.e. the PDF or even better an SVG version to start with. I tried both formats, in “normal” and large print. After popping them all into Adobe Illustrator, I clicked around to find the version which had the most amount of clean separation between layers. Turned out the PDF Large Print tube map was a reasonable starting point. I use that adjective loosely.
Spring cleaning
This is probably the most laborious part, but equally the most important to make this thing actually any use. Unfortunately with compressed PDFs, text fields are nearly always seperation in order to preserve the display of the typography as accurately as possible, making lines split into words, and words split into meaningless 1 or 2 letter “phrases”. This is great for the human eye, but for actually ‘querying’ the document, it’s useless as we need clean labels for each tube station.
Essentially the job was a manual one. I’m no Illustrator expert so there may well have been easier way, but it surpassed me if so. Here’s a demonstration example of what I did:
Oxford Circus -> Oxford Circus
Do you see? To start with, we had 5 different (and meaningless) labels, “Ox”, “for”, “d C”, “irc” and “us.” Do you also see how I used the Tube line colours for my demo?
By now I’m sure you’ve figured out how I spent that evening…
Seperate the Tube lines
Now we have the station names cleaned up and ready for conversion (I’ll explain how in a minute), it’d make it even more interactive if we could distinguish between the Tube lines themselves as well. Filtering just on the Central and Picadilly Lines, for example.
This part is a bit simpler and is actually a really simple technique of getting complex paths into Raphael JS.
I simply selected each line in Illustrator, and copied into a new standalone document. I then Saved a Copy, selected SVG 1.1 as the document format and clicked Show SVG Code. I was presented with this little beauty for the Central Line:
<?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 13.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 14948) --> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="400px" height="400px" viewBox="0 0 400 400" enable-background="new 0 0 400 400" xml:space="preserve"> <path fill="none" stroke="#ED3024" stroke-width="6.65" stroke-linejoin="round" stroke-miterlimit="3.994" d="M973.98,129.223 H773.97c-4.87,0-11.67,2.823-15.12,6.269L629.99,264.364c-3.45,3.44-10.25,6.258-15.12,6.258h-79.49 c-4.87,0-11.66-2.817-15.11-6.258l-33.239-33.236c-3.44-3.448-10.24-6.264-15.11-6.264H-572.959"/> </svg>
I’ve highlighted the bit we need. This can then be used as simply as:
var c = paper.path("<<< PATH CONTENTS HERE >>>");
…and so on for each line.
Getting the stations into Raphael JS
This is the final stage really. Unfortunately there’s no such easy technique for getting text labels into Raphael type code. After a bit of playing around, I wrote a PHP script to help me with this.
All you need to do as save the stations, and the stations only into a document. This does mean a lot of copying and pasting, or a lot of deleting of tube lines and artifcats, whichever your preference. However, with this done you should just have a document with a bunch of text labels which you save as an SVG 1.1 file somewhere.
Running this PHP script on it will loop through every SVG text node, extract the text and the x and y coordinates for you; making it super easy to plot all the hundreds of stations exactly where they were in SVG, using Raphael.
header("Content Type: text/plain");
$xml = simplexml_load_file("stations.svg");
foreach($xml->children() as $child) {
if ($child->getName() == "text") {
$matrix = $child->attributes();
$matrix = str_replace(array("matrix(1 0 0 1 ", ")"), "", $matrix);
$matrix = explode(" ", $matrix);
// here we go
$stationName = trim(str_replace(array("%%", '’'), array('\n', "'"), $child), " ");
$x = $matrix[0];
$y = $matrix[1];
// your business logic here
// echo($stationName);
} }
One last thing to note is that it seems line breaks (which are essential to mirror the layout of the Tube Map) are converted into seperate text fields when saving down to SVG. For this reason, and its not the cleanest solution I admit, I tokenised the strings with “%%” to represent a line break, which were then converted into line breaks using the code above.
Using that script I printed out the exact Javascript variables I needed for the project I was working on for this at the time, looped through them all and created them as text fields:
var stations = { "Oxford Circus" : { x: 100, y: 100 } };
for (p in stations) {
var station = stations[p];
var t = paper.text(station.x, station.y, p);
t.attr({font: 'Arial', 'font-size': 13.5, fill: '#1C3F94'});
}
SVG and Illustrator file references
As a farewell I will leave you with the 2 SVG files which took the most time to produce and will do most of the work for you. I’m sure they could be cleaned up even further, and I’m open to any suggestions on how to do so.
SVG Source for Tube Stations
SVG Source for Tube Lines
All should be labelled clearly for ease of use. Good luck!


