So ems. I’m not going to go into what ems are, if you don’t know then have a read of this fantastic article by Chris Coyier. My base font size is standard (16px) and I use this calculator for px to em conversions. (All my calculations in this article are based on a 16px base font size)

So my media queries used to look like (separate CSS docs, mobile first approach):

href="style.css" media="screen"
href="assets/css/min-30.css" media="only screen and (min-width: 480px)"
href="assets/css/min-48.css" media="only screen and (min-width: 768px)"
href="assets/css/desktop.css" media="only screen and (min-width: 1170px)"

This has now been swapped for: -

href="style.css" media="screen"
href="assets/css/min-30.css" media="only screen and (min-width: 30em)"
href="assets/css/min-48.css" media="only screen and (min-width: 48em)"
href="assets/css/desktop.css" media="only screen and (min-width: 73.125em)"

Pretty straightforward conversions but as I delve a little deeper into my CSS it does get more complicated. What about borders, box-shadows and border radius etc.

Say if I wanted all the content on my site to be at 75% rather than 100% I simply change my body font size to 0.75em (75%) and all the units are modified accordingly because of this one change. For larger divs and containers this isn’t a problem. But what about a 0.063em (1px) border? By reducing the base font size we have actually made this border smaller than a pixel after its recalculation.

I’ve done some testing on Trent Walton’s website who has used ems for his borders. If I take his default font size to 75% on Firefox it still displays fine (below left). But on webknit no border appears at all (below right)!

Obviously this is quite an extreme example, and if you’re not going to decrease your default font size (as Trent probably isn’t) then there aren’t going to be any problems. But is this a case of overdoing it on relative units?

I’m not entirely sure of the solution here but I think I’m going to stick with using pxs for smaller things such as borders purely because I know it works. It’s certainly the safe choice. I guess the only way to find out the best way is to try and test different methods.

Oh and other thing

On my Base template I use % widths when the media queries kick in. If I’m using % widths with px borders I’m never going to get exact sizes. This is where changing the box model comes in handy (width + padding + border = actual visible/rendered width of box).

Any comments don’t hasitate to comment below or hit me up on twitter @webknit

I have recently started a new job at McCann and I’m now employed as Junior developer. At my last job I was just a “front-end dev”, and I rarely touched anything other than HTML/CSS. So in other words I’m moving over to be a “back-end” boy too. I know bits and bobs of JS, PHP, AJAX etc but not enough as I should do.

I’ve started reading a book on JS and jQuery (which I would highly recommend) and I’ve learnt some cool stuff already. I find it’s easy to read books but I don’t learn anything until I’ve built/coded something (hence the reason I have too many sites). You get tasks to do in the book but there’s not much point following the tasks as you’re not using much initiative or putting stuff into practice.

So I’ve made a new site. It’s called Function and it’s going to feature a collection of programming projects that will be built by yours truly. I’m starting on JS/jQuery and when I’m decent at that I will be moving onto some other languages.
The initial projects are pretty simple. We have Rock, Paper and Scissors and Lotto, an app which picks random lottery numbers.

All the code will be added to my Githib so that anyone can make use of it. There has also been talk of some “guest” features, where some other devs feature their work on the site. So if anyone’s interested shoot me a mail/tweet/pigeon.

You can view the list site here – www.function.webknit.co.uk.

I used to add a class to something like this…

html class="no-js"
body class="no-js"

Then I would simply remove the class when it reads the Javascript/jQuery

$('html').removeClass('no-js');

$('body').removeClass('no-js');

There are a couple of reasons as to why I am now against this approach.

• Javascript should be loaded in the footer of a page, so all the CSS is read first (including the no-js styles) and then the class removed once the browser reads the JS. The could cause the page to ‘flicker’ between the two sets of styles. Something we really need to avoid.
• After learning to code mobile first. It is only right that I should embrace a progressive enhancement approach for JS too. In other words my no-js styles come as standard and my ‘advanced’ JS styles come after. (Only the advanced styles are declared, no-js won’t exist)
• We should use JS as opposed to jQuery as we would have to load the library in first.
• We should apply the advanced class to the HTML tag as it is the first element that is rendered.

So now my HTML tag doesn’t include a no-js, or advanced class. It is simply.

html lang="en"

The I use the following code snippet to add an ‘advanced’ class onto my html element if JS is enabled.

document.documentElement.className = 'advanced';

And style something like this.

.movingElement {display: block;}

/* The following is hidden initially then uses JS to add move functionality */
.advanced .movingElement {display: none;}

The are loads of other ways this can be done including using modernizr, but this is the approach I am now using. It has been added to my Base template if you want to check a working example out.

For those of you who don’t know what I’m talking about – a sprite is basically multiple graphics compiled into one image. So a common use is where a button has an “on” and “off” effect. Both these effects can be within in the same image (sprite) and the background position can change on hover. Sprites can contain multiple images, so you could include buttons, graphics and just about anything you want, just simply move the background position to show each one.

Every time anything (including images) is loaded in the browser it triggers a HTTP request to collect it. The more requests a web page makes the slower it will be. Because these requests need to be kept to a minimum it makes sense to load one large sprite sheet full of images as opposed to loading multiple individual files.

I have found some very useful tools which assist with spriting (A term I made up):-

• Sprite cow is awesome. You basically upload an image and select it in the browser and it tells you the exact size and location of the image on the sprite sheet.
• Sprite Pad, this is cool. You drop the images into the site and then download the sprite image and also a CSS document with all the CSS on it.

There are probably a load of other tools which I don’t know about. Another thing that was mentioned to me was Compass which has some nice sprite features built in. I need to give that a try.

The bigger picture

I have a tendency to look at the bigger picture with things these days and this subject was no different. How big can you go? How many sprite sheets should you have? What do you put on each? How are they organised?

On smaller websites it doesn’t really matter. You can just add all the images to one sprite and code it up. But what about larger sites with lots of images. Well firstly I think the sprite sheets need to be organised properly, so buttons, icons, round corners could be one. Images and photos another, banners another. It obviously depends on your project but if something needs to be modified or located it’s essential you know where to find it.

The biggest question is how big should you go. A reliable source at work advised me that some mobile devices won’t load sprites bigger than a certain size. Not only this but remember the browser has to download the whole spite before it displays any of them. This is something that needs to be taken into consideration. Especially bearing in mind the new “retina ready” (2x) images.

Although it was hard to find some bulletproof information I did find out the following:-

• The limit on the older iTouches, Original iPhone and iPhone3G is a max image size of 1024×1024
• Later iPhone 3GS, iPhone 4, third-generation iPod touch, and the iPad support a max image size of 2048×2048
• iPad2/3 and iPhone 4s supports 4096×4096 as far as I know.

You can read the full specs for apple products here. I’m not going to bother looking for android spec as they will no doubt be similar. I’m not too fussed about the early phone models these days. I won’t cater for them unless I need to at work. But I won’t be going over that 2048px X 2048px figure for all future sprite projects. Nice fact to know.

How you make them

How would you make the sprites? Would you do them right from the start or drop them all into one document after you have finished coding and use one of the tools I mentioned? You could do either, and I suppose it’s a matter of preference.

I personally would make the sprites as I code up a new design and insert the background-positions as I go along. I would have the PNG sprite file open from my img folder and keep re-saving it and adding the CSS.

Drawbacks

Are there any disadvantages to using sprites?

The biggest pain is updating the graphics. Imagine a small arrow icon on a sprite sheet. You have to locate it first and then cut it out, swap it for the new image and reposition the image with the CSS. You need to make sure you don’t cut any of the other sprites out, I have messed up a few times cutting shadows or transparent layers which are difficult to see on a PNG file. I would highly recommended always saving your sprite file as a PSD with all the layers (native files). It’s much easier to manage and swap images.

Conclusion

For the majority of sites with a small amount of traffic it probably doesn’t matter. Or at least you think it doesn’t matter.

I think it’s important to do things correctly regardless of whether they matter or not. Take my sites for example. I’m getting around a 1000 hits a day now on my four websites and because they were badly coded in the first place the loading was slow, and I’m wasting unnecessary data and peoples time (something I’m working on fixing).

So yeah speed and performance of websites is a big thing these days, reduce your HTTP requests where possible and supply the correct size images, you will be a better web dev for doing it!

• I never use it.
• Most people who do use Base either use SASS or standard CSS.
• Now that I am familiar both I want to focus my attention on one CSS extension.
• SASS is better in my opinion.

So firstly I want to say sorry to anyone that has been using my template with LESS. The standard CSS will always be present so no need to worry about that. But the LESS, well, it’s gone.

It want to start thinking about my code in a modular way from the very beginning to ensure larger projects are much cleaner and well structured and smaller/simpler projects can easily be stripped down. To help me achieve this I have added several SASS @import modules. I don’t want to go over-board with this and my main aim (as always) is to create a nice base that can be expanded, but at the same time is adequate to start with.

All my CSS is still based around the _style.scss file. Here’s a little bit of code to show you how these imports work. The modules are simply imported into my _style.scss file. If any of these modules aren’t needed then they can simply be deleted. If more are require then stick some more in. It’s pretty easy to see the benefits.

/*********************************************
- 3.0 -  SASS
*********************************************/

/* - 3.1. - Colours, Backgrounds, Gradients
------------------------------------------ */

@import "imports/colours-gradients";

/* - 3.2. - Mixins
------------------------------------------ */

@import "imports/mixins";

Modules

So what modules have I included? Have a read below.

Base-elements – Headers, lists, blockquotes, paragraphs, img
Colours-gradients – List of site colours, gradients
Font-face – Includes @font face code
Forms – Form styles
Links – Hyperlinks, buttons, header links
Mixins – Includes all SASS mixins

I use Codekit to compile my SASS code, each time I save one of these import files it automatically sticks the code into the _style.scss file.

My initial thoughs and maybe yours are that this approach is overkill. Too many folders and file names, surely it’s easier to just have it in one file? For smaller projects I would agree yes, but imagine a huge project with 10k lines of code, creating separate modules will make things much neater and convenient.

Another benefit would be the fact that styles can be reused very easily across a range of stylesheets for a project or even on other projects.

Thoughts

I don’t expect this transition to be problem free. No doubt I will run into issues along the way but trial and error is most defiantly the best way to learn. One issue that springs to mind is the use of nesting in these modules. It will need to be kept to an absolute minimal to ensure the styles can be reused anywhere.

Base has had a complete new re-design. Much simpler and easy to manage, it also looks decent! You can view base online here and on Github here.

This new site should be fully responsive and is built with the amazing WordPress CMS. As always, I have gone for a very minimal look with maximum use of white-space. My fonts are being served by typekit and they are Minion Pro, Museo Sans and Coquette. I have made this site with HTML5 and CSS3 (SASS).

I couldn’t be bothered to wait until I had made sure this site worked across all browsers so if you find a bug let me know. It’s a work in progress.

I really want to start reading, writing and ultimately learning more, hence the reason I have made this new blog.

Here’s a few things I have on my to-do list.

• Get to grips with JS and build some kind of app
• Get all of my code onto Github
• Re-design of Base
• Go to the .net awards ceremony after my nomination for best online portfolio.

Cheers for reading and I promise to update this again soon.

The Island is only accessible by boat or plane. Naturally we went for the most exciting and expensive option with the plane. The plane was an 8 seater and it was terrifying. It was the smallest plane I had ever been on and the wind was atrocious. We landed on the island and there is certainly no public transport or taxis there! We walked up to the hotel to be greeted by the lovely hotel owners, found out some information and then set off to take a look around.

Our preferred method of transport on the island was a push rod. Complete with suspension, mud guards and a bell. It was an absolute pleasure to ride.

We set out on our tour of the island and took some fantastic photos. The island is incredibly remote (150 people) and the terrain is very bumpy and consists mainly of limestone. Houses are scattered about the island, some still have thatched roofs whereas others are more modern. The island has one hotel, one shop and a pub. They live incredibly basically and it was fascinating to see their world in comparison to mine. The focus of their lives is on verbal communication, most of which is done in Gaelic. They don’t really have any money so materialistic goods are very rare. Some families had chickens, cows or pigs and they would also grow their own vegetables.

After delving a bit deeper into the islanders I found that many of the residents were in fact on the dole (much to the uproar of the mainland people). It’s a tricky situation, they are Ireland citizens and need to be accounted for but there is absolutely now way they are able to obtain employment. There is nothing on the island besides a clothing factory, airstrip, boat docks, the pub and a small shop.

The boat to the mainline costs around $20 return, drops at a remote Galway location and takes over an hour. No job is really viable unless it paid decent money. The islanders are just happy to get by taking the money and living peacefully and simply on the island. Some have been innovative and taken advantage of the little tourism they experience by hiring bikes which was nice to see.

Anyway we finished the photographs for the day around 2-30pm, absolutely freezing and headed back to the hotel where we were greeted by a roaring fire. We got straight on the ale, and made friends with some other American visitors and had a great chat with the hotel owners and some other locals. 5 pints and a little nap later we headed straight up to the local boozer and plonked ourselves in the cosy little bar which had around a dozen islanders inside. The inhabitants seemed to be very reserved and cautious towards us initially but we soon won them around. Amazingly at 11pm 60 young Irish students came from nowhere and entered the pub (they were on the island for 2 weeks learning Gaelic) we had a fantastic night and eventually walked home in the pitch black around 3am.

The next day we went to see the rest of the island and stumbled across some famous landmark where John Millington Synge, a famous Irish playwright used to sit and write his scripts. We said our goodbyes and made our way back to Galway, then Cork and finally Liverpool again.

Back in Liverpool we headed to a £25, dive of a holiday-inn near Runcorn, logged onto our internet and the next day we went to see old Trafford, had Frankie and Bennys for dinner and then Rob got the train home (notice anything dissimilar?).

I appreciate the way the Islanders live their lives and admire the way in which verbal communication is fundamental to their lives, something that has changed beyond recognition in the UK since I was a small boy. However I am more than happy to be back on my Macbook pro, watching sky and writing this blog post on the Internet. It was a great three days but I’m too accustomed to my life in the UK to think any other existence would be better.

Thanks for reading. Take a look at some more of my Instgram shots below!

It’s been a year since I managed to obtain my first graduate job. I was writing down what has happened to me nad my skills since then and I’ve whipped it into a messy blog post. I’m half decent now but by no means an expert. Hopefully any web designer can relate to some of the stuff I mention here.

This time last year I was pretty shit if I’m honest. I wasn’t the smartest person in the class and I probably didn’t have the best skills. But what I did have was a passion and dedication for web design. I lost count of the amount of sites I made and I was always trying something new and reading books.

Oh and I was employed about 12 weeks before I graduated from university (2 day week) if you’re wondering.

How I learnt

My favored way of learning web design was to pick a website I liked from an inspiration website and try to replicate it. The results were often shocking and barely resembled the original, however I used to enjoy comparing them and evaluating why mine looks crap. Looking back now I can say it was generally a mixture of poor typography, layout and content in addition to a general lack of detail.

When I left university my coding skills were very, very basic. I knew how to make stuff but half of the code I wrote was very unpractical and just really messy. I remember I used to duplicate CSS styles over and over rather than just giving them all the same class.

In addition to my lack of skills, other major issues during the transition from university to a real workplace included:-

• Some things I hadn’t really experienced before such as SVN,  Terminal commands, local site setups, hosts, IP addresses.
• Timekeeping was very difficult. It was tough to say how long something WOULD or even SHOULD take you.
• Becoming part of the team was tough. Knowing how account managers operate. Knowing how designers make their sites. And knowing how to pass work onto other developers.

Importance of the workplace

In reality there are loads new of skills that can only really be absorbed through work experience. Just looking at some of the senior members of staff and seeing how they operate, code and communicate is a massive learning experience in itself.

I would say that I have learnt about 50-60% more in the workplace than I did at university. It’s ok knowing the basics at university but putting them into practice is an entirely different thing altogether. I used to become incredibly nervous during some early projects to the point where I couldn’t sleep. Am I doing this right? How should I code this? When you barely know anyone in the workplace asking a question is a nightmare. I would ask the most ridiculous questions sometimes. But it’s all part of the learning experience. Everyone that you ask would have been in the same position at some point so never worry about asking questions as long as you are actually taking the information in.

One of the biggest things I have learnt to do is relax and think about things before getting worked up or making a decision. The amount of times I was given a task or bug and all I could think was “SHIT How am I going to do this”. Once I start panicking I am never going to make rational decisions. I’ve now learnt to take a step back and analyse the situation. And while you’re in the situation there is always someone you can rely on. Google. He’s become my best friend!

When things go right

As you get better you start to feel really good. There is no better feeling than creating your first site from scratch and seeing it go through to live. It’s ace. As my skills improved so too did my status in my workplace and my relationship with my workmates. About three months in I started to feel relatively comfortable each time I was allocated a task.

Once I starting working my passion for web design seemed to escalate quickly.  I became obsessed with reading books and knowing everything I could. I was making at least a website a week. I was coding/reading/designing day and night and I’m lucky because I love it.

Obtaining employment

The best thing I ever did was to focus on my online presence. In my latest job my new boss told me that he didn’t even look at my CV, and why should he? He doesn’t care what grade I got or what modules I sat. He wants to inspect my code browse my websites and resize his browser. I made a few websites and they were innovative, half decent and looked ok. I’m still amazed that some graduates don’t even have their own websites when they apply for jobs. That to me is just unbelievable.

I’ve come a long way since I left university but I’ve still got so much more to learn. The good thing about the web community is that most people are eager to help you and give advice. The amount of tutorials, inspiration and blog posts I see everyday is unreal.  I have lost count of the amount of times I wanted to re-design all my websites because I have learnt something new.

My aim

My personal aim is to be a very competent front-end developer in three years time. I want my work to be seen as first-class and to be trusted with any project. I feel it’s very important to keep on learning and reading as technologies constantly evolve and things change very quickly. Luckily I’m now at a fantastic workplace and surrounded by some very talented folk who are always happy to help me.

I’m hoping my passion for Web Design is going to stick around for a while yet because I’m really enjoying web design and everything it entails.

For anyone who doesn’t know .net is the world’s best-selling magazine for web designers and developers and it is basically awesome to be associated with it.

You can check the site out here. Don’t forget to vote for me.

My website is here.

Firstly it’s important to say that although I am normally right, I may not be right here. It’s a matter of personal preference. Everyone has different ways of doing things. I will, however, try and give a fair summary of Mobile first with both pros and cons for you to make your own decision.

Traditionally every web designer has approached the desktop side of any project first, of course they have, desktop is prehistoric whereas mobile is new born baby in comparison. Once mobile came onto the scene it was thought logical/practical to make desktop first and then work DOWN to mobile.

Over the past few years this Mobile First approach has taken the industry by storm and although I have heard everyone ranting on about it I couldn’t for the life of me understand what on earth they were talking about. Where is the logic of making the mobile version first? Even just thinking of it now, I think I may have gone insane just taking about this approach, but the main reason for this post is so that I can read it when I get confused and reassure myself I’ve made a logical choice.

Firstly the mobile market is HUGE. I think everyone knows that. I’m not going to go into the facts and figures of this, just stand where lots of people are and look around. You will see mobiles, lots of them.

Graceful Degradation vs. Progressive Enhancement

Yes this old chestnut.

Graceful degradation means to create and serve the best experience possible and and then account for each possible degradation and ensure that site remains functional throughout. As regards mobile web design this means that the full website would include everything and then content would be removed etc as the viewport gets smaller and the system simpler (For example a flash video could be removed on mobile and replaced with an image).

Progressive enhancement is a little different. This means you put your best stuff forward on mobile to the best of its ability and then as the viewport gets wider the site is enhanced for larger platforms with fewer constraints.

I can write what those two mean off by heart after having to learn them at university but I still don’t really understand the difference (Who cares as long as the client is happy with everything?).

Graceful degradation means that I will make my desktop version amazing, making use of all that screen size and technology and then cut bits out and change things to get it looking right on mobile. The mobile version will just be “something you did after the main bit”. It may sometimes look great but chances are that it will just feel more like an afterthought rather than a polished site.

With progressive enhancement I get my mobile version looking spanking and then I continue to improve my website on desktop. I’m not hiding anything and I’m not watering anything down, I’m just deciding how to enhance it and make it more robust.

There is a little bit more to it though. If we design for desktop first then we are making images, text and videos for the desktop version. What usually happens is things are hidden from the mobile view. There are two problems with this. Firstly why on earth are you hiding something that you want people to see? And secondly the content will get downloaded whether it’s hidden or not resulting in longer loading times for something the user won’t even see.

Design for mobile first, get it looking smart and loading fast and then load any other stuff you require after. Simple.

First of all your stylesheets should be separate. Imagine the example below being one massive stylesheet and you are loading on a 768px screen . Its going to load the whole page when you only really want half.

@media only screen and (min-width: 320px) {

LOADS OF CSS

}

@media only screen and (min-width: 768px) {

LOADS OF CSS

}

Do I have to say why this is crap? Get them split up and defined in your <head> like below.

<link rel="stylesheet" href="320.css" media="only screen and (min-width: 320px)">

<link rel="stylesheet" href=" 768.css" media="only screen and (min-width: 768px)">

Going mobile first isn’t easy. It’s difficult and takes time to learn, but so did learning to code and that was worth it yeah? I’m fairly confident that the benefits of coding mobile first outweigh the challenges.

Most responsive websites I see have max-width media queries setting elements to display:block, float:none, max-width:100%, etc… as the viewport gets narrower.

For most elements developers are applying the above styles to; divs, headers, footers and sections. These are the default styles for these elements. So by starting mobile first, you never have to write these styles. You only have to apply styles to the elements that need to change from their default style as the viewport gets wider. With this approach, your code will be smaller overall and therefore, faster.

The important thing to remember is that you base CSS styles are for MOBILE. That is the one thing I couldn’t get my head around. Your mobile styles go in the base.css files as do all your default styles. You then add extra styles as the viewport gets BIGGER.

Cons

The biggest problem that is apparent to me is how to design for mobile first. That seems much more difficult than coding mobile first! But I don’t know too much about that as I’ve not tried and I tend to design on screen!

After writing all that I am honestly struggling to think of reasons why I shouldn’t do it this way? Yeah, it’s hard, it wasn’t fun changing my process but now that I understand I’m better off. RWD gives me more options not less. I should be embracing my mobile users not just thinking of what they will see after I’ve done my desktop.

It is, however, very frustrating starting with a smaller screen and fewer resources and is probably the main reason why some people won’t get involved.

I think the reasons for mobile first speak for themselves. The cons seem to be more personal. But what have you got to lose by trying it (besides from the fact its standard procedure for most decent RWDers). If you’re a bit worried about learning new skills and trying new methods then you probably aren’t a good web designer anyway.

I’ve updated my Base template and made it mobile first. Get it downloaded and have a look. Once it clicks you will never look back.

Honest.

Thanks for Colin Rotherham for helping me see the light and assisting me with my queries on Base.