Category Archive: HTML5

  1. Geolocation

    Leave a Comment

    Geolocation has been around in the spec for a while, but hasn’t really taken off on the desktop as yet. It’s hugely common in mobile apps for it to ask for your location, but rarely for websites to request this information. Such information can provide localised information relevant to where the user is, and whilst hugely beneficial on mobile devices when out on the go, such information can be put to good use on the desktop as well.

    One example where this is used effectively is on the Pizza Express website, where upon sharing of your location will display the nearest restaurant to where you are, and contact information for the restaurant as well as a clear call to action to book a table at the restaurant.

    Such a simple use of this technology is effective and one which I feel provides a lot of benefit to the user and could be easily implemented onto more on sites. Coming up I will demo how to create a simple call to ask for the user’s location.

  2. HTML5 Changed Elements

    Leave a Comment


    As well as the well-documented additions to the HTML5 spec, a number of elements have had their meanings changed to reflect the changes in the way websites are built and also some previously deprecated elements have been brought back so to speak and now have valid, semantic meaning, allowing us to use the b, i and s elements again without the need to feel dirty whilst we do so!

    A list of the changed elements is listed below:


    The anchor elements changes in the manner that block-level links are now valid code. This has been supported in browsers for a while, but is now valid. Also, using the name=”#id” convention is now obsolete which was typically used for in page navigation. Instead, apply this technique to it’s containing element. The target attribute is now no longer deprecated “as it useful in Web applications, particularly in combination with the iframe element.”

    The media attribute is new and can be used in conjunction with CSS media queries.


    The b element has changed from the presentational meaning of bold text to “offset text conventionally styled in bold”. This doesn’t appear to be a massive shift in definition but is a way of separating out content from it’s surroundings without providing any extra meaning. The em and strong attributes embolden the text but provide emphasis on the text, whereas the b element has no extra meaning and is useful in a range of situations.


    The cite element refers to the title of a cited work, and not an individual as previously defined. Cite should not be used to mark up a person’s name and instead refers to title of work, ranging from a document to music to games or in fact anything that is referenced in a document.


    The hr element used to be a purely presentational element which was used to insert a horizontal line on the page, though it has now been given the meaning of a “paragraph level thematic break”. This means that it can be used to break up a paragraph or to indicate a change in content – it can be used to provide a transition between content within a document and provides a link between the two.


    The I element is similar in meaning to the b element in that it used to be a purely presentational element and now represents text that is offset from it’s surroundings but provides no extra emphasis. Anything that is usually presented in italics, but requires no emphasis then the I element should be used and there is no need for extra spans messing up your markup.


    The menu element has changed from a “single column menu list” to specifically referring to a list of commands. Potentially more useful in web applications as opposed to traditional websites, the type attribute declares whether it is a toolbar or a context menu. If no type is defined, then it represents commands that are neither a toolbar or context menu.


    The s attribute was a purely presentational method of applying a line-through to text, however this has been changed to be given the semantic meaning of “struck text”, which is text that is no longer accurate or relevant. An example of this would be previous prices on e-commerce sites, I’ve been using this element to mark these up and has the benefit of more semantic meaning and no need for presentational span elements.


    The small element was also a presentational element which referred to text which was to be rendered as small. This has now changed to be given the semantic meaning of “small print” and refers to content such as copyright notices, or links to the development company of the website.

    All of these elements valid code that can be used today in practice without fear and with the benefits of reducing mark up and the need for styling additional span elements which add clutter to our markup and also provides more structured, semantic meaning to our code.

    An excellent html resource and a great place for keeping track of the changes is in fact the HTML working draft, which is available on the W3 site

    Thanks to David Reece for the photograph.

  3. The Unknown Elements

    Leave a Comment

    The Unknown Elements

    There are over 100 elements in the HTML specification, and it’s fair to say that some are more used by others. Elements like div, ul and table are used on almost every project whereas some are rarely used such as kbd, var and wbr. Some of this is down to browser support and I’ll be honest in my case some down to ignorance of it’s existence.

    I’ve done a bit of research into some of these lesser known elements and listed them below, and I certainly intend to use them more in projects now where appropriate.


    The base element is a way to declare a base href for the document, which is then used by the relative urls on the page. There is a maximum of one base element per page and is a similar syntax to normal a elements:


    The var element is used to markup variables, or text that represents a variable value. In a maths or programming concept, it represents a value which is a variable, or can be used to indicate a value which the user will mentally replace with a custom value.


    The samp element is used to mark up sample output of a program. Again, more suited to web applications than standard websites, it’s used for sample output for example a demo of a process or system which generates a value or result depending on a user’s interaction.


  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. 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.

  8. The time element and WordPress

    Leave a Comment

    Wordpress and the Time Element

    I’m currently in the process of re-designing this site and part of this process means updating it to utilise the latest HTML5 and CSS 3 elements where possible, and as a result of this I’ve used the time element in all dates such as post date and also other dates.

    The format of the time element for dates is as follows:

    <time datetime="2009-11-13">13 November 2009</time>

    The datetime attribute has to contain an ISO 8601 date although the value can contain any date format you wish. When using this with the dynamic nature of wordpress, the following format produces a valid output for post dates:

    <time datetime="<?php the_time('c'); ?>"><?php the_time('F jS, Y'); ?></time>

    This will currently produce valid HTML5 and can be used in addition to “pubdate” to indicate that this was the date the article was published.

    <time datetime="<?php the_time('c'); ?>" pubdate><?php the_time('F jS, Y'); ?></time>

    Of course, time can be used elsewhere on the site where suitable, and in any string format you wish.