My recent adventure in writing a jQuery plugin led to me considering what other notionally unattainable client-side information could be gathered using a bit of Javascript and CSS manipulation. A bit of playing, (and a lot of understanding Safari’s rather greedy method of storing styles) has resulted in my second jQuery plugin in as many months.

With the same disclaimers about elegance and infallibility, this plugin allows you to test a user’s browser history against specific URL, returning a true/false value if they have visited the site in question.

Much like my previous effort, this plugin works by creating an HTML element, in this case an <a> tag, and some associated CSS properties to alter the element in a measurable way. In this case, by adding some very specific styles to the :visited property of the link that can be measured in a fairly precise manner if the link has been visited in the past.

This isn’t a bulletproof solution, however. You can only blindly test against the browser history, so need to make educated guesses and allow for changes in a URL, (such as trailing slashes or additional query string parameters). I’ve found that testing for one or two minor variations gives the best result – I might even add some minor intelligence to the function to account for this.

As before, the plug-in is of beta quality but seems to work in Safari 3, Firefox 3+, and IE 6+. I’ve created another example page, where you can also download version 1.0 of the plug-in in uncompressed and compressed form.

Author’s Note – This is a reproduction of a boxout written for the ‘Exploding The Myths Of Web Design’ feature in .Net magazine, issue 189.

Have you ever been handed a design for a website and wondered what font the designer has used for the body copy? Because I can honestly say I never have, and this certainly isn’t down to web designers having a love for Georgia and Arial. Instead, it’s down to a common misconception that the only fonts that can be rendered in a browser are the old ‘favourites’. The thing is, a modern web browser is perfectly capable of rendering any font that a user has installed, and because of the popularity of particular software packages, the list of relatively commonplace fonts includes some beauties.

On 24 Ways, Richard Rutter showed that if you take into account fonts installed by Windows and Mac OS X along with those from Microsoft Office and Adobe’s Creative Suite, the resulting list includes some rather lovely serif and san-serif fonts that a designer can use to bolster their designs. With some carefully selected fall-backs, there’s no reason why a good developer can’t provide users with Caslon or Jenson in place of Georgia, or Helvetica Neue in place of Arial. By using the CSS font-weight property, you can even use differing weights further enhance your work.

Most websites are launched to a specific audience or demographic, and if they aren’t then your marketing team is missing a trick. If you have a good idea who will be looking at your site, it’s then easy to treat them to some nicer typography. For example, Panic achieves this on the company’s website for FTP client Coda by using Helvetica Neue Light, after surmising that the majority of visitors will be Mac OS X users, who have the font installed on their system by default. Even if you don’t have such a targeted audience, you can still play the percentage game, and in doing so, you can at least treat a portion of your visitors to a more refined, unique look. Call it typographic progressive enhancement!

I’m a massive fan of pushing the typographic capabilities of our current crop of web browsers and the supported HTML and CSS standards. I’m not talking about embedded fonts or Flash/Javascript-based font generation but using simple CSS rules to bring nice fonts to the user, if available on their system. Richard Rutter, Guillermo Esteves and myself have all published tutorials on how to include non-generic font families in your CSS declarations - the very same methods that allow me to use Adobe Caslon Pro on this website.

These methods are excellent for progressively enhancing the typography of a website, but are, (rightly so), based on providing a carefully selected set of fall-back fonts should the favoured family be unavailable. At present, there is no elegant way to determine whether your chosen font is being used and, if not, which of the numerous families in your font stack are instead.

Although I am loathe to call this solution elegant or fail-safe, I’ve tried to solve this problem by building a jQuery plug-in that should shed some light on which families your site is rendering in, and allow you to alter a site’s behaviour, content or appearance accordingly. I’ve created a demonstration page that uses the plug-in to show which of the fonts you currently have installed and enabled out of a list that is fairly arbitrary, (the fonts currently active on computers around the Outside Line office).

The plug-in works by generating a paragraph of text, outside of the viewport, in a monospaced font. The paragraph is measured and re-rendered in the test font, (if available). If the paragraph dimensions change, then the rendered font must have too, and so the family must be installed/enabled.

Usage of the plugin is fairly simple, returning a boolean true or false value when you pass in a CSS-style font-family declaration. You can also pass in, optionally, a font-family declaration that you know is different in dimensions and available to test against, should the defaults not work so well.

The plug-in is of beta quality, and has only been tested to the extent of the fonts available to me. It works in Safari 3, Firefox 3+, and IE 6+. A lot will depend on the font names/post-script names/family names of the fonts you are testing for, as they tend to differ between vendors. In terms of example usage, aside from the demonstration pages, I’ve updated the about section of this site to deliver a more relevant message describing the design of the site. You can download version 0.1 of the plug-in in uncompressed and compressed form.

Outside Line are looking for a LAMP developer to join our team in Exmouth Market, London. We need someone who is obsessed with producing efficient code, fast queries and well-structured applications. We use the Codeigniter and Zend frameworks, but appreciate you might have experience with another MVC set-up. Bonus points will be awarded, (in order of importance) for any experience in internationalisation and/or localisation, server administration and putting the milk in before the teabag/water. We ideally want someone with agency experience looking to step up to a bigger league and make their mark.

You’ll be working with extremely talented designers and developers, and me, at a top UK agency on projects for clients such as Queen, Paul McCartney, Oasis, Cravendale, the BRITs and Diesel. You’ll be joining a tight knit studio that love producing exciting content for the web, (with a bit of table football and Gears of War on the side).

Salary will be dependent on experience and is negotiable. No remote workers, people who can’t work in the UK or recruitment agencies. If you are interested, email your CV and code examples to bens@outsideline.co.uk.

Outside Line are looking for a front-end developer to join our team in Exmouth Market, London. We need someone who is obsessed with producing clean, accessible and semantic mark-up and loves nothing more than pushing browsers to their limits with CSS and Javascript, (particularly jQuery and/or Prototype). Bonus points will be awarded, (in order of importance) for knowledge of PHP, MySQL, CodeIgniter and MVC and putting the milk in before the teabag/water. We ideally want someone with agency experience looking to step up to a bigger league and make their mark.

You’ll be working with extremely talented designers and developers, and me, at a top UK agency on projects for clients such as Queen, Paul McCartney, Oasis, Cravendale, the BRITs and Diesel. You’ll be joining a tight knit studio that love producing exciting content for the web, (with a bit of table football and Guitar Hero on the side).

Salary will be dependent on experience and is negotiable. No remote workers, people who can’t work in the UK or agencies. If you are interested, email your CV/portfolio to bens@outsideline.co.uk.

Apache’s mod_rewrite functionality allows you to redirect and rewrite your web site URLs, providing a developer with an easy way of creating human readable, well structured and, most importantly, navigable page addresses. It’s used by almost all Apache-based software from Wordpress to Codeigniter. Enabling it within Apple’s latest iteration of Mac OS X is, unfortunately, a bit of a fiddle.

Updating the Apache configuration to allow the use of this functionality is achieved by modifying two files, one for the global web-server directory and one for your local web-server directory, (the much easier-to-access ~/Sites folder). The first file to be modified is the global configuration file, and it needs to be modified around line 205.

The second file, allowing you to use mod_rewrite within your own ~/Sites folder, is the one that seems to break Apache on a more regular basis. The values below, located at the top of the file, yielded the best results, enabling the functionality without causing server errors.

After making and saving these changes, you’ll need to restart Apache, (easily done via the ‘Sharing’ system preference pane, just un-check then re-check the ‘Web Sharing’ checkbox). If everything went well, Apache should start up again and you should have full mod_rewrite functionality.

The separation of a web site into structural, presentational and behavioural layers is the key to making a usable, accessible and future proof web site, and the fact that CSS and unobtrusive Javascript allow us as developers to do this has been a major factor in the uptake of web standards. The reason this separation is so important lies in how it allows so many devices to access your data in so many ways. Mobile phones see a different version of your site to Safari, which sees a different version to JAWS yet all access the same mark-up and the same URL. Maintaining this separation intelligently is the key to allowing as many users as possible to access to your data using any means they want.

Many web developers are still falling quite short of this separation, not because they are using tables for layout, inline styling or obtrusive javascript but because they are ordering their mark-up not by how it is used but how they want it to appear. The structural layer of a web site should focus on enriching your content semantically to provide a user with the content they need in the most accessible way possible. This doesn’t just mean using suitable heading hierarchies, lists and labels but also ordering your content properly to provide suitable focus to the most important parts of the page.

Users who visit sites with devices that support limited or no CSS, or with devices that do not display your content visually will not see your content in the organised columns and colours that the majority do – they will be browsing your site in a single column ordered as your mark-up is. This often means they first receive a long list of navigation items, logos and introductory paragraphs when what they really want is the latest article, train time or number of goals Thierry has scored today.

There seems to be a growing trend for developers to include ‘skip to content’ links as a solution to this problem. These links bypass the navigation and header elements and move the user straight to the content, but users still have to move around a page instead of being served what they want straight away. This technique also fails to account for other ways in which your data is accessed; search engines indexing your pages may rank prevalent content more highly for example, and they won’t use skip links to pursue the content you deem most important on the page. Although I am not an SEO expert I can’t believe that important, relevant elements at the top of a page won’t have more influence on a search engine in how it interprets the meaning of your site.

There are plenty of CSS techniques that can be used to separate your page structure from appearance – the excellent methods explained at Position Is Everything for creating columns in any order on the canvas, for example. Just remember that the most important column is the one containing what the users came for.