Category Archive: CSS

  1. Preload web fonts

    Leave a Comment

    Custom web fonts have been around on the web for a number of years, and became much more popular with the advent of services such as Typekit and Fontdeck.  In addition to these font services, there are a number of sites that allow downloading and hosting of custom fonts such as Font Squirrel and Google Web Fonts.

    What they all have in common is that the fonts are all lazy loaded – which means that the fonts are only loaded and rendered when a CSS selector has a matching @font-face rule.  In order to download these fonts, the browser has to download and parse all HTML and CSS to search for any matching rules before applying the font changes.

    This response is intentional, giving the advantage of only downloading font files as and when they’re needed and requires no superfluous connections initially. This approach represents poor performance as the amount of web fonts being used has increased significantly over the last few years.


  2. Patterns and Systems

    Leave a Comment

    When it comes to creating templates from static mockups, there are a couple of approaches that you can take. One is to follow the mockup and create exactly what has been made available, and another way is to create a system which can be used and re-used as the site evolves and grows.

    This systematic approach is one that I now adopt on almost every project I work on, creating as many layout agnostic elements as I can, so that when it comes to creating the layout these elements can be added in anywhere. Website designs by their nature have a level of consistency in terms of colour and typography which will be repeated throughout the site. By creating a system first before creating the layout of the site, I find that lends itself to writing less CSS and creates a more flexible codebase.

    A couple of examples of these systems are Jeremy Keith‘s Pattern Primer and Paul Robert Lloyd’s Styleguide and Barebones project, which I both use on a regular basis. I feel this makes creating templates much easier but also makes maintaining a site much easier as well.

    I tend to create a styleguide which will have a list of almost every HTML element styled in a consistent manner, but I will also include examples of any common JS that is included such as lightbox scripts so that if another developer comes to work on the site they can see at a glance what is being used on the site and avoid any duplication of code.

    I now take this approach on each project and I would recommend it to others.

  3. New @font-face syntax

    Leave a Comment

    New @font-face Syntax
    The availability of fonts that can be used has grown massively over the last couple of years, with services such as Typekit and Fontdeck taking the hassle out of serving fonts to the world. Services such as sIFR and Cufon are now largely out-dated unless in certain circumstances (corporate fonts for example may need some protection from publishing the font file on the server). One of the most common ways to embed custom fonts on a webpage is through the @font-face declaration, and there is a new syntax which should be used now which handles Android devices and IE9 a lot better, and also is a lot cleaner and easier to maintain.

    The syntax is:

    @font-face {
    font-family: 'MyFontFamily';
    src: url('myfont-webfont.eot?') format('eot'),
    url('myfont-webfont.woff') format('woff'),
    url('myfont-webfont.ttf') format('truetype'),
    url('myfont-webfont.svg#svgFontName') format('svg');

    I think you’ll agree that’s a lot easier to understand and maintain. The question mark at the end of the eot declaration is the key here, so head over to Font Spring for a full explanation of the new syntax.

  4. Websites can’t look the same, so why try?

    Leave a Comment


    It’s an age old argument and one that still rumbles on, but with the expansion of devices, emergence of HTML5 and CSS3 and the continual decline of Internet Explorer and older browsers, it brings it into even sharper focus. It is impossible to make a website look exactly the same on an iPad as it does in IE6 as it does on a BlackBerry as it does in Opera Mini, so why do we waste countless hours and lots of our clients money trying to make the websites we create the same in every browser?

    IE is still the most popular browser, although with it’s usage now below or around the 50% mark, then we’re almost at the point where the IE argument is becoming null and void. Why should the 50% of users with the most modern browsers be punished and served an experience way below their browsers capabilities in order to please the other 50%? Is it not better to spend a bit more time and care taking full advantage of these emerging technologies in order to serve an experience and design which is appropriate to the device and makes full use of it’s potential? Yes, the older and less capable browsers won’t be as slick and polished but when designed effectively then the message is still communicated in a clear manner and nothing is lost as the user is still able to access the content, still able to purchase the items they want to buy and do everything else they came to do on the website.

    The way fonts are rendered across the range of devices and operating systems immediately rules out any possibility of sites looking exactly the same everywhere and with the new CSS3 properties allowing us to create shadows, borders and rounded corners with only a few lines of CSS, as well as transitions, transforms and animations then we have even greater power at our fingertips. These emerging techniques mean we now have the ability to tailor the designs and experiences we create to the browsers and their capabilities, so users get the best possible experience for the browser that they’re using.  If we start at the bottom and take the opinion that websites must always look the same, then we give ourselves an artificial ceiling meaning that we rule a lot of these new techniques, and short change both ourselves and the website owner. New techniques are ruled out because “it won’t work in IE” and our markup becomes littered with empty divs and spans all so we can absolutely position a drop shadow, or even worse include even more hefty JS to a page so that corners can be rounded.

    We should be taking the opposite approach and starting with the most up to date techniques and technologies and providing alternatives to other browsers so that it’s the best it possibly can be within that environment. Plan to use 3d transforms and transitions in designs, and carefully craft alternatives for the less capable browsers. We do this when creating font-stacks, we pick our optimum font, possibly with @font-face or services such as Typekit or Fontdeck and we load it up and away we go. We start with the best and then declare fallbacks, so why don’t we do this with everything else as well? And if a drop shadow or rounded corner is an essential design element that must be seen cross browser, why are we so often using JS to render these? Javascript is an enhancement which adds to the design and shouldn’t be used for critical elements.

    We have a wealth of techniques at our disposal from media queries to keyframe animations to canvas elements all the way down to the humble rounded corner and drop shadows which can and should be used right now to enhance our designs. When used properly, they add a level of polish and finish off a design to a great level. Currently, a lot of people would take these “added extras” and use a combination of JavaScript/proprietary filters/presentational markup in order to achieve this in every browser, when a more sensible approach would be to use the modern standards that have been developed and serve each browser an experience which is appropriate to their capabilites. Loading  up older browsers with extra files and scripts slows it down and lessens the experience for those users, all in order to maintain the archaic notion that every website should look the same in every browser. It may look the same but the fact that it’s now so heavy in order to serve these effects mean the experience is vastly altered in a negative way, and we all know that as well as not looking the same then they don’t have to be experienced the same either. Is it really worth slowing down and adding weight to pages purely so that box can have a 3px border?

    Take the time and alter the layout when switching from landscape to portrait mode on the iPhone/iPad, use media queries to target smartphone browsers, check against more basic mobile browsers as well as testing on the desktop browsers and all the usual stuff like without JS, smaller resolutions and not just check to see if they’re ok but optimise them as best you can for these conditions. The web is not a static medium and we have no control over how a user will access a site, but by optimising for the most common scenarios then we will cover the vast majority of use cases, and cover them to the best level we can.

    I think we’ve truly reached the point where we should be binning this idea of everything looking the same everywhere, by taking the time to craft these different experiences then we are able to create better websites which are easier to maintain, often able to develop quicker and deliver a more cost effective solution for our clients and better experiences for our users.

  5. Review: 2010

    Leave a Comment

    Review: 2010
    As it’s been a while since I’ve written a blog post, I thought the traditional end of year post would be a good place to round up.

    This year has been quite eventful, as I started the year as a full-time student working part-time from home and ended it out of education and working full time with a different employer. As I’ve written before, I wasn’t entirely happy with university and my original plan was to finish the academic year and consider my options over the summer, deciding whether to carry on or seek full-time employment. As it turned out, I was lucky enough to be offered a position with a company here in Dundee and I can honestly say I do not regret leaving uni one bit. I’ve learnt far more in 6 months of work than I did in 2 years of university, and am thoroughly enjoying it.

    For 2011 I have a few goals, with the main one to become much more fluent in JavaScript and jquery. I feel my HTML/CSS skills are at a good level but my js needs some serious work. I’m not horrendous at it and can implement basic things such as slideshows, hide/show etc no problem but I’d really like to become a lot more fluent and knowledgable about it in order to write custom functions and better scripts.

    Something else I’d like to improve greatly is my actual design skills, and spend a lot more time crafting in Photoshop and then implementing in the browser. Or design in the browser but either way I’d like to become much better at designing interfaces from scratch. One way to do this would be to create a psd on a regular basis and to brush up on design theory etc so that I know what I’m doing, and able to improve.

    As well as improving on my skills as a designer/front end developer, I’ve a couple of personal projects that I’d like to work on throughout the year, nothing big or extravagant but something where I can flex my muscles a bit and put into practice some stuff in a real live project. I’d like to have something up in the first quarter of the year but we’ll see how I get on.

    I’m looking forward to 2011 and hopefully it’s as good as last year.

  6. HTML5 – Can we use it?

    Leave a Comment

    It's the Future!
    Last week I inadvertently started a debate at work about how much HTML5 we can use/get away with in client work, with me firmly in the camp of using as much as we can and the HTML5 shiv should be leveraged to serve layouts to IE. For me the advantages outweigh the supposed pitfalls, and by continuing to be restrained by older browsers, including our old favourite, then we’re not only not doing our jobs properly, we’re letting our clients down.

    (*Note this is a general argument, not taking into account site specifics such as stats etc.)

    For me, the bare minimum we should be doing is switching over to the new HTML5 doctype and begin to take advantage of as many features as we can such as the new form elements, and format of javascript links etc. HTML5 has been designed to be backwards compatible so switching to the new doctype will have no ill effects at all.

    Personally I would go one step further and begin marking pages up using the new structural elements such as header, footer, section, article etc, making use of Remy Sharp‘s excellent HTML5 shiv to display these elements properly in IE. I know there are accessability issues surrounding the use of javascript to render page layout, as those users without javascript will see a poorly rendered layout. I’m usually a firm believer in everyone being able to access a site regardless of the device they’re using and it’s capabilities, with javascript adding extras which if taken away do not affect the functionality of the site. However, with HTML5 now at a mature level and with IE6 still hanging around I think it’s time we took a step and dragged users along a bit by beginning to use these new elements and serve javascript up to IE and older browsers.

    I understand the reasons for being wary of this approach, it’s not fully accessible, relies on an externally hosted file and introduces an extra point of failure for the site if the external file can’t be loaded for some reason. However, the number of users with javascript turned off is negligible and with the rise in popularity of use of frameworks such as jQuery and MooTools means that those small percentage of users will be well used to websites not looking spectacular. For me the benefits now outweigh the drawbacks and we’re not doing as well as we can by sticking to the tried and trusted methods and we should be pushing the envelope a bit further if possible.

    For me it’s not a question of whether we use HTML5 (or some of the newer CSS3 declarations), but how much of it we use?

  7. CSS Flip Experiment


    CSS 3 Flip Experiment

    Having attended the DIBI Conference in April and been witness to the brilliant presentation given by Andy Clarke, I was fascinated with a technique he demonstrated with pure CSS of items appearing to flip over on hover, and wanted to try this for myself. I had the ideal project coming up which was an end of year university site that required building, and this would have been perfect for it. Each “card” was going to have an image of the module and when flipped over would have some text information and a download link of the work. Alas, I wasn’t successful at the time and had to abandon that idea as time ran out.

    I was still determined to figure it out though and I’ve kept returning to it in the months since until I finally cracked it!

    Take a look at the demo.You’ll have to be using the latest version of Safari to see it in it’s full effect

    I know this is a long way from web standards and being able to use in client work but it’s good to experiment and know what’s possible. To achieve the effect makes heavy use of webkit only properties such as -webkit-backface-visibility, -webkit-perspective and -webkit-transform-style

    I won’t go into the full code structure but the technique is achieved by hiding the back until it is hovered using -webkit-backface-visibility and positioning to achieve. Feel free to look at the full HTML and CSS to see how it was done.

  8. Media Queries

    Leave a Comment

    Media Queries title=

    CSS media queries have been around for quite a while, with CSS 2 introducing media=screen and media=print also available to create print stylesheets, but CSS3 has added to this with the new media queries which allows much more targetting of browser types. These allow different stylesheets or different rules to be targetted by declaring the widths of browsers. Examples of this include:

    @media print {
    body{width: 100%}

    Or more advanced targetting such as:

    @media screen (max-width: 1024px) {
    body {background: #fff;}

    The CSS spec states that:

    A media query consists of a media type and zero or more expressions that check for the conditions of particular media features. Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself.

    This means that sites can be optimised to both the device and screen resolution, although one could argue that by hiding certain elements on smaller devices is changing the content. For example, if this site is scaled down to 800×600 the “about” section on the homepage is not displayed, as this prevents horizontal scrollbars and is not essential. Users can still access the navigation and the latest posts, but I feel that this information can be removed and not alter the experience too much.

    Media queries have received a lot of attention recently with the A List Apart article on Responsive Web design and excellent uses of the technology by Simon Collison and Jon Hicks, and whilst I was impressed with them I held off from experimenting with it for a while, as I didn’t know too much about them and they seemed a little scary!

    However after experimenting with them recently on this site, it’s a really simple technique of over-riding your default stylesheet with specific styles for the devices and browser sizes stated. Although screen resolutions are increasing and very few users are still using 800×600 or even 1024×768, the art of progressive enhancement means that these users shouldn’t be ignored and media queries allows sites to be tailored to these users. Resize your browser to see how this site reacts to smaller browser sizes, although there are more impressive examples out there.

    Having played with them now and seeing the power of what can be achieved, I’ll definitely be making use of them in future projects, both at work and in personal projects.

  9. eCSStender


    HTML5 and CSS 3 have been around for a good while now, and more and more of it can be used on client work, although we’re not yet at the stage where we can throw off the strict doctype completely and create extravagant sites using canvas and SVG and all the other css goodness around such as animations and transforms. We can use smatterings of this stuff, border-radius, box-shadow can easily be used now, although in general they’re used for the extra touches on websites and elements that won’t affect the main design or critical elements of the page.

    There are a few ways to add in CSS support for unsupported browsers using JavaScript but nothing that really offers a one stop simple solution for achieving decent CSS 3 support cross browser, and one service which was recently announced was eCSStender, which promised that by downloading and including a couple of JavaScript files that a wide range of CSS 3 techniques could be implemented cross-browser, crucially without any vendor prefixes required.

    Recently, I was working on a project which would have benefited from this library as development time would have been drastically reduced with the benefit of cross browser compatibility for techniques such as border-radius, box-shadow etc and I began coding with this in mind.

    There was initial success with Firefox recognising the standard border-radius without the need for the -moz- prefix, and this appeared to work cross-browser. Except for Internet Explorer, any version. After many attempts at trying to get this to work, I gave up.I recently heard that border-radius was not supported in IE with eCSStender, and I’m wondering what all the hype was in the A List Apart article. It was billed as a simple solution to easily achieve CSS 3 compatibility, but if something as simple as border-radius doesn’t work in IE then what’s the point? There are other ways of achieving compatibility and eCSStender was not all it was made out to be in the article.

    It was billed as the saviour to vendor prefixes and greater flexibility, whereas in reality it is none of these.

  10. Site Re-Design


    Site Re-Design

    Not even a year since the last re-design, it’s that time again. Whilst I liked the previous design at the time, it wasn’t too long before I started getting the itch to re-do it again. I wasn’t entirely satisfied with the design after a while and recently found the time to re-do it again, keeping the same loose structure and style but updated slightly and less cluttered I think.

    For a good while I wanted to include as much information as possible and the site didn’t always have room to breathe and there was limited amounts of whitespace, but this time I’ve tried to space things out better and provide more whitespace to display the most important elements of the site clearly. The same structure is kept as before but just slightly altered to show off the content a bit more.

    The site is built using HTML5 and CSS 3 wherever possible  and as such looks better in the good browsers and should gracefully degrade in the not so good ones (hello Microsoft!). IE6 I didn’t bother wasting my time with this time, very few people visit this site using that browser and it wasn’t worth my time. Instead, I served it the excellent Universal stylesheet from Andy Clarke. The site works fine in IE7 and IE8 although it doesn’t have all the bells and whistles that it should have. I also upgraded to WordPress 3 and have been playing about with the new custom post types, I’m not quite there with it yet but should have them fully set up and working soon.

    I also created a custom iPhone stylesheet which displays the site in a basic manner at the moment, which will improve over the next few weeks as I learn more about creating a specific iPhone stylesheet and improve on the usability and experience of viewing the site on an iPhone. At the moment, content is displayed but it needs more work to improve on the basic layout it currently has.

    There’ll still be more improvements and tweaks to the site over the next few weeks as I don’t think it’s perfect and there are areas I need to work on, but I felt it was ok to release and work on the relatively small tweaks over time.