Creating Favicons

When creating a site a favicon is pretty much a must these days and it has always bugged me that creating a favicon isn’t straight forward. For one thing different browsers support different standards of favicon, most modern browsers support png images but older browsers only support bmp images. Generally speaking this isn’t an issue and the .ico format allows for this as essentially it is simply a container format which contain several images, a browser in general will choose the most appropriate image for the correct right situation, and you can even specify which icon to use using a meta tag.

Creating an .ico file however which contains several files can require a specialist piece of software which usually isn’t free. You can of course use an online service to do this but I have had mixed results in creating them with this, especially when you want to provide many alternatives.

I have stumbled across a different method. You can use plain old ImageMagick to create them. Simply use the the following command:

convert image1.png image2.png image3.bmp favicon.ico

And that’s it, a favicon is created containing all of the images.

LessCSS unitless mixins

When doing development and you need to dimensions to a block element in CSS its pretty tedious to write:

.block {
width: 200px;
height: 200px;

I use LessCSS as my css pre-processor so wrote a handy little mixin to shorten this:

.size(@w, @h) {
width: @w;
height: @h;

Then to use it in the example above I would use:

.block {

Not much of a saving but when you do this 20-30 times in a less file the savings can add up. One thing that always bugged me though was that I had to pass through the px in the mixin arguments. I thought the way to get round this would be to change the mixin code to:

.size(@w, @h) {
width: @{w}px;
height: @{h}px;

However this always resulted in a syntax error. I guess the variable interpolation isn’t that great. I have however solved this today to achieve the simpler .size(200,200) that I am after use this funky syntax:

.size(@w, @h) {
width: ~"@{w}px";
height: ~"@{h}px";

Lovely jubbly or to extend it further in case you want to throw in a different unit but default to pixels:

.size(@w, @h, @unit: 'px') {
width: ~"@{w}@{unit}";
height: ~"@{h}@{unit}";

Local Domain Without Hosts File on OSX

Where I do a lot of local development I need to set up a lot of virtual hosts etc for each new project. I’m always looking for ways to shave a bit of time off this process and make it quicker and simpler to set up. In general all of my projects follow a similar pattern. I assign a 3 letter code to the project and use this to set up a local domain, always in the form of xxx.localhost. This convention in general makes things very quick for me but I still end up having to edit a few files to set up a new site.

One thing that has bugged me for a while is having to edit my hosts file to add a new entry. In DNS world I would have a wildcard domain *.localhost which mapped to my machine, however this isn’t available in the hosts file so I ended up having to manually add it each time and my hosts file contained hundreds of entries.

Today I deleted all those entries and instead set up dnsmasq to create a *.localhost situation. It was fairly straightforward, only bit slightly difficult was the need to add to the list of DNS servers. I use Macports, but Homebrew is just as straightforward.

  • sudo port install dnsmasq
  • vim /opt/localhost/etc/dnsmasq.conf
  • add “address=/localhost/” to the end of the file
  • sudo port load dnsmasq
  • Open up Network preferences, add to the DNS Servers List
  • ping xxx.localhost – should return

That’s it. A wildcard DNS for *.localhost set up and working. One less file to remember to edit.

Remembering Nana Kath

I’ve thought quite hard about writing this post mostly because I am not too comfortable with public displays of emotion, things like what I am about to write are private. However this is no ordinary circumstance and I’d like to be able to look back in a few years time and remember how I felt and what this person meant to me. This post is for me.

Yesterday at about 5:30pm my Grandma passed away.

In simple terms I am devastated about this, my grandma was the only grandparent I knew, I don’t remark this in a bitter way its simply how life ended up. So devastated, yes, but in other ways I feel joyous and pleased. Joyous and pleased, for rather than this being a tragic situation, a life taken away in its prime, an unexpected shocking demise, it is a chance to celebrate a remarkable life.

Nana Kath, as she was known to everyone was just over 100 years old. Now in years to come this may not be a remarkable age, but today it is. Think about this, my Grandma was born Sept 22nd 1912, thats two years before the first world war. In 100 years she has lived through a lot and seen unprecedented change.

Unfortunately I couldn’t give you the history and life story of my Grandma, there are many facts I would end up getting wrong and 65 years had already been and gone when I was born. What I can tell you is that during all of the years I was privileged to have with her I have rarely met a keener mind. Her memory always amazed me, she recount stories from her childhood as if it was yesterday. In another time and place she would have achieved so much, but shackled by circumstances and the time of life she achieved everything a mother, grandmother and great-grandmother should.

Right up to the age of 100 she lived an independent life, a quiet life in the heart of yorkshire. She lost her beloved Charlie nearly 30 years ago, a long time to be apart.

In her last few years she was loved and remarked a sense of awe by all she knew and met. Her 100th birthday party being a fantastic celebration where she far outlasted even the most optimistic expectations of her. Family and friends from far and wide together in appreciation.

The last 6 months have been hard and in the end I like to think she knew it was time to go and I am thankful for the small mercy of her not suffering. Its time to be reunited with Charlie.

In her final days in hospital two tales epitomise my Grandma for me. When she was first admitted to hospital her first remark to the nurses was:

I hope you’re not going to put me in a ward with all the old folk.

And when a nurse found out she was 100 she asked whether she had received a telegram from the Queen and if she had put it up on her wall, her reply was:

Oh yes I got one of those but there’s no room for it on my wall, its full of important pictures of my family.

She kept her humour to the end and even in her wane was still a shining light.

R.I.P. Nana Kath, I love you.

LessCSS, Import and Media Queries

Today I found out the Media Queries are not supported at all in IE8. Not sure how I missed this, only that I haven’t used media queries extensively in any project until now. I have just finished off a site that has an adaptive layout for table and mobile. Having completed the majority of development in Chrome and I yesterday moved on to the dreaded cross-browser testing.

To my surprise when I open it up in IE9 there was appeared to be no serious issues. A pleasant surprise, the text lacked text-shadow in a few places, but this is an aesthetic issue not a downright broken issue so I can live with it. Feeling bolder I moved on to IE8 and was very disappointed when the site was a wreck, not slightly broken but very broken.

This was a bit unexpected as I tend to develop using well known patterns which only occasionally need tweaking. Something else must have been the issue. Following a brief conversation with a dev friend he pointed out that IE8 doesn’t support media queries. All of my layout and navigation was defined in media query, hence the massive fail.

The solution was a straight foward approach:

  1. Copy the CSS out of the media query into a separate file
  2. Conditionally include it in the header for IE8 (and below)

This approach does however pose a maintenance overhead, if I make changes to the desktop CSS this needs to be carried through to the external file. Ideally I want to be able to maintain one file which is referenced in the main file. The media query spec does not allow you to use a CSS import inside it, so this approach is not available.

Fortunately I use a CSS pre-processor to create my CSS, I use {less}, less allows you to use multiple files and import them into a single output file. My approach was to simply copy the less into an external file and use the @import syntax in the main file. I could then reference the compiled external file in a conditional comment.

@media only screen and (min-width: 769px) {
  @import "desktop";

This did not work unfortunately, the less parser currently does not understand this construct and the import is ignored. It is a well known issue and has been discussed for some time. It is fixed for now in the master branch and is scheduled for the 1.4 release but isn’t out yet. Instead I have used the following work around.

Wrap the code required in a mixin in an external file (desktop.less) i.e.

.desktop() {
  less code...

Then import the code outside of the media query and call the mixin inside the media query (main.less) i.e.

@import "desktop";
@media only screen and (min-width: 769px) {

Finally I created an extra file which includes the code outside of the media query which can be compiled and conditionally added (ie.less) i.e.

@import "desktop";

One file to maintain, compiled into the main CSS file, and and another CSS file for conditional inclusion. When 1.4 is released my first approach will be available and you won’t need the extra file, until then this is a good work arund.

Ignoring the 10%

Browser support and cross-browser testing is a tricky subject. As a veteran of the browser wars I’ve seen a number of browsers dominate for a while then tail off as a new generation invariably comes through. In each generation we as web developers look to be in a better place but are always seem to be held back by the legacy of previous generations.

Back in the early 2000’s there were basically two browsers of note (I am deliberately generalising here and am well aware there were more than two browsers) IE6 and Netscape, roughly speaking it was a 90/10 split. IE6 was the ground breaking browser, way better then Netscape, and it was believe me. As a developer you spent most of your time developing to IE6 well aware of the fact it probably broke a bit in Netscape. Never a comfortable situation but it did allow you to take advantage of the better features in IE6 which seemed a good compromise.

Fast forward a few years and the next chapter in the browser wars, the standards movement. Raising Microsoft out of their slumber it pushed the web forward, IE7 was awful, IE6 the bane of developers lives with IE8 and Firefox the leading lights. It was bad for a few years but we moved forward, slowly but surely we started leaving behind IE6, sure there was still 10% of people using it but sacrificing these users for the good of the 90% was acceptable.

And now we are in modern times, Chrome has emerged as the new darling of browsers, IE9/10 makes it again one of the contenders, Firefox is still in the mix and everywhere mobile is the new must support platform. And then there is IE8… Yep you guessed it, representing about 10% of your users.

Given the importance being placed on mobile as a platform, and the fact that most mobile/tablet computers have fairly good support for modern standards is it time to sacrifice the 10% again. Some big sites and big players such as Google have already signalled the end of IE8, is it time for this to become the norm? IE8 usage will only drop and mobile looks set to increase, in my eyes the time is now…

Going Responsive

There’s no doubt that with the proliferation of mobile devices in recent years web site design has gotten a lot more complex. It is now more than ever important that you offer the best experience to your site visitors no matter what device they may be accessing your content through. Offering a mobile optimised experience is a time consuming exercise for a developer, and maintaining two codes bases for your sites can be problematic.

In recent years there has been a large movement towards offering the best of both worlds in a responsive site. A site which isn’t constrained by the fixed dimensions, that works equally well on a large display or a small screen mobile device.

I haven’t touch the design of my site for a couple of years now. I went down a “design” by iteration route until I got to the point where I was happy enough with the design that I stopped. Since then I have wanted to update the site on a few occasions and even got to the point where I have been tinkering with the layout, fonts and overall design. What became clear as I was doing this was that making the site that I already had responsive was not going to be a quick and easy task.

Today I have decided to drop my theme and instead of wasting my time on creating a theme use the latest in-built theme from WordPress. I have installed and activated <a href="" onclick="_gaq.push(['_trackEvent', 'outbound-article', 'http://wordpress why not try these’, ‘Twenty Twelve’]);” target=”_blank”>Twenty Twelve, the new responsive theme from wordpress.

It takes all of the heavy lifting out of the design and what I end up with is an extremely flexible design which not only functions extremely well in the responsive world but also in my opinion looks great as well.

I’m sure over the coming months I will add my own little touches here and there. I also still haven’t given up on the idea of creating my own responsive design, however I think I will use my commercial site to work this out on, so stay posted for news in this area.

WordPress Custom Post Types

As I use WordPress more and more on a professional basis I am discovering things that make using it as a CMS more and more useful. Over the past couple of years I’ve had quite a few projects based off of WordPress and one of the things that makes me cringe the most is seeing a page that is made up of multiple parts or content types. The classic example of this is a homepage which has some sort of slider on it. The slider invariably needs to be content managed, and quite often so does the text from within it.

I have always solved this issue previously by simply creating a slide template and creating pages which are assigned to this template, usually as child pages of the homepage. A page has a few common parts, title, body copy, featured image which can all be used to create the content. Then if there are other structured requirements you can use custom fields on a post to add these elements. Overall the standard page functionality can be manipulated to achieve the desired result. This approach works, to some degree but it isn’t user friendly and can frankly be a pain to use.

Another way of doing this is to find a plug-in which adds slide functionality, and there are a large amount of plug-ins of varying quality which do this. I hate plugins in general, the quality of them is outside of your control, they can break or hinder the upgrade path unless actively developed and often they add bloat to your theme. Sure they are much more user friendly but as a plug-in is often a generalisation of the problem rather than a specific answer to a problem a plug-in doesn’t always fulfill your requirements.

The third and final way is basically a mash of the two, custom post types. A custom post type is often basically what a plug-in is. However as you are defining it you get to control it. Where you are using custom fields you get to layout the edit screen in exactly the way you want to, label the custom fields appropriately and make the creation and updating of the content much more intuitive and user friendly.

There are 2 things you need to do to get custom post types working:

1) Register the post type

register_post_type( 'home_slide',
      'labels' => array(
        'name' => __( 'Home Slides' ),
        'singular_name' => __( 'Home Slide' ),
        'add_new_item' => __( 'Add New Home Slide' ),
        'edit_item' => __( 'Edit Home Slide' ),
      'public' => true,
      'show_in_menu' => true,
      'supports' => array(
      'rewrite' => array( 'slug' => 'slide' ),
      'exclude_from_search' => true

2) Create the code to define the post type. I won’t go into detail on this one but I found the following tutorial useful to get me started:

From now on I will be using these on a lot more word press projects.

Non Native Form Controls

Been a while since I did a blog post, been probably the busiest I have ever been over the past 3 months, but I have been a bit disappointed that I have let my blog suffer as a result. Continuing in a slightly negative vein I’d like to post about something that as a developer I just don’t get.

I’ll freely admit that I’m not a designer and that if I was I’d probably get just as annoyed when looking at a design where something doesn’t quite fit in with the overall feel as when I see a piece of code which is not as aesthetically pleasing. However if the code works I’m inclined not to change it, after all if it ain’t broke don’t fix it. So why, if there are such compelling reasons not to, do designers insist on changing the look of native form controls? Specifically I am talking about <select> and <input type=”file”> for fields, although this can easily be extended to checkboxs, radio buttons and to some extent submit buttons.

I won’t argue as to the how good or bad they look as to me its a bit of a non issue, but I can come up with some fairly compelling arguments as to why changing them, probably through the use of JavaScript is a bad idea.

  • Native controls are bullet proof – by this I mean the browser makers have spent considerable amounts of time coding and testing the native controls to ensure they work correctly. They have found and fixed all of the hundreds of edge cases, as opposed to a JavaScript solution which potentially cannot handle a multiple selection use case, or a list which is 1000 options long.
  • Native controls are future proof – what happens to your JavaScript implementation when a future browser gets released that changes the way it handles scroll events? Native controls don’t suffer from this, they will work in future releases as the browsers makers test them for you.
  • Native controls are familiar – everyone who browses the web will have come across a native control, will recognise is and will be fairly comfortable with how it works. In terms of usability you can’t trump that.
  • Native controls are accessible – going back to my first point, native controls have a lot of inherent accessibility built in, you can use the mouse or keyboard to interact with them and things like screen readers are well aware of them. Unless your JavaScript implementation covers all the same use cases that a native control does then you are simply using a inferior form element.
  • Native controls are (more) secure – a standard file control has a lot of security built in. Drag/drop interfaces whilst nice don’t always have this inherent security built in.
  • Native controls are cross browser compatible – you don’t need to worry whether your JavaScript implementation works in IE6, it just does.

This list isn’t exhaustive but it does highlight the advantages of using native controls. I’ll give a couple of recent examples.

For a project I recently did one of the requirements was to be able to upload a file via a public interface. The design had a lovely branded purple browse button and accompanying , which granted probably looked better than the standard browse button. I explained at the start of the project that styling a file form field is difficult to do and I wouldn’t recommend it. Regardless it went ahead, but I caveated my quote with a non guarantee that it would work cross browser. I styled the button using a JS implementation and for the most part it worked. I then got a bug report that it didn’t work in Firefox 14, sorry I can’t guarantee it will work. Not a huge deal as it turns out the work/won’t work scenario was intermittent (great!!). Next is this doesn’t work in iPad, well no of course it doesn’t file fields don’t work in iPad, thing is that on an iPad the native file field would be greyed out and disabled, the styled file field isn’t, there are probably a hundred mobiles that this is the case for. If we had used a native form field both of these problems would not have been a problem, it still wouldn’t have worked on an iPad but at least the user would have known.

The second example (from the same project) was that a drop down menu that had been styled didn’t work in Safari 6. It was another JS implementation, fairly good cross browser support and had recently been updated so still actively maintained. But still it had certain use case where it didn’t quite work as intended.

I’m not going to argue that layering on top of native form fields isn’t a viable progressive enhancement technique especially if there is a good usability case for improving the functionality. However to do it for purely design reasons ignoring the disadvantages of doing so doesn’t seem like the brightest idea to me. Stick what CSS can do and you can’t go far wrong, bring JavaScript into the equation and you’re asking for trouble.

Now I have to get on with some work, ah yes a lovely dropdown menu design sigh…

Clash Of Clans Cheat And Hack Tool

MD5 Insecurity

The following post is about security, I am in no way a security expert, far from it, but this is basic basic stuff. OK hands up, who can tell me what this is? 5f4dcc3b5aa765d61d8327deb882cf99

The average person may say a code of some sort? A slightly more techie person may say its an encrypted word? A even more techie person may even be able to identify it as an MD5 hash? And someone with moderate technical experience would be able to identify it as the MD5 hash of the string “password”. And that people is the issue, if you can easily identify the single string you could easily hack a lot of web sites.

A lot of websites require a login of some sort. You know the drill you’ve done it a thousand times, register for this site with an username/email and password. Some sites may go as far as imposing some password complexity rules, but a lot don’t, and you probably end up using the same password for every site you register for. This is an accident waiting to happen. Why? Well because when you register for a site you expect the developers of the system to be competent people who know what they are doing with your sensitive information. Let me tell you now they don’t, and it is beginning to scare me more and more.

Any developer should know at least one thing about security, don’t store the passwords in plain text. Simple answer encrypt them? Find a one-way hashing algorithm (such as MD5) and store them encrypted. That way if anyone got hold of the database then they wouldn’t know what your password is. But increasingly this is wrong, OK I’ve encrypted them using MD5, but as I’ve shown from the example above anyone who is stupid enough to use the password of “password” I know what it is, it may as well have been stored as plain text, and this unfortunately is true of every single word in the dictionary, and also unfortunately true of just about every random string of letters and numbers up to a reasonable length.

So at the very least if you are encrypting passwords add some salt to the beginning, end or both. Salt changes your 8 character password into 32 character+ passwords and makes recognising the password “password” much more difficult. That any developer friends is the very least you should be doing, add salt to your passwords please please please. But in reality you shouldn’t be using MD5 anymore, its insecure, and SHA-1 isn’t much better either but at least its a step up. My recommendation would be to set the minimum bar at salted SHA-1 encrypted passwords.

The reason for this is that I am getting more and more amazed at how many registration systems don’t do this. I’ve come across many a home grown system that just MD5’s the password, and even some fairly big systems, Drupal 6 being one of them!!!

And this is the problem, all it takes is a site of sufficient size getting hacked (like linkedin for example) who only use plain old MD5 and your password can be determined. Same password for most sites = trouble. And this is probably the case. Your password may only be as secure as the weakest password on the site, which is a scary thought these days.