Firstly, to counter the somewhat curmudgeonly tone of the title, I am definitely not the oldest or most experienced web developer—I’ve only been in this industry for seven or eight years, five or six professionally. However, I do remember when many aspects of web development were far more difficult than they are now. I remember trying to track down randomly appearing content in Internet Explorer 5, (that’ll be HTML comments after a floating block element), and why we used @import to link to stylesheets, (so Netscape Navigator 4 didn’t try to interpret them). I even remember the level of work it would take to support non-Javascript users, because having it enabled was not nearly as prevalent as it is now. By comparison, with the resources and information available to developers and the relatively good browser support we have, today it is pretty easy to get designs to ‘work’ in even the most reviled browsers.

So why is it suddenly so fashionable to advise developers to drop browser support for certain, often non essential, features? To not use certain proprietary fixes because they aren’t valid? Worst of all, why is it okay to advocate that if a client doesn’t agree with your views, you should turn away their business or quit your job in protest? It seems to be that, as it has become easier to build sites, developers are more determined to keep their code clean, less inclined to implement fixes and, most importantly, happier to sacrifice a subset of users for technical benefits that only they will really understand. The industry is so close to being in a golden age of reliable rendering engines, support for exciting advancements in technology and the focus shifting from ‘making things work’ to ‘doing cool stuff’. Unfortunately, we are not quite there yet, and impatience seems to be increasing.

My first, major issue with these opinions and those who express them is that, as I referenced so wistfully above, browser support is nowhere near as difficult as it was even three years ago. So many nasty browsers have fallen by the way side and those that haven’t can be extended with great examples of ingenuity. In this light, dropping browser support so often smacks of laziness. Of course, if the portion of your audience using a certain platform is negligible, and your client is happy to sacrifice them, and there is economic value in doing so, go ahead. But every case is extremely unique, and these articles seem to forget that. There almost certainly isn’t economic value in shunning even 1% of your users because you have to use a proprietary filter over a valid CSS property, or an almost certainly pre-existing Javascript work-around. You are kidding yourself if anyone but you really cares.

The second, more important, issue that I have is how un-constructive this opinion of educating your clients or firing them can be. It used to be that developers would publish inventive workarounds and document bugs so that bugs could be more easily fixed. Now they are happy to advocate an approach that 99% of their audience cannot feasibly take. In the current economic climate, not many freelancers can afford to drop a client. More importantly the majority of developers won’t be freelancers, and they are never going to resign over having to implement a fix or support a platform they don’t like, (and if they did, their CV isn’t going to be worth much to future employers—I certainly wouldn’t have hired a developer likely to walk out if they didn’t get their own way).

I am absolutely in favour of using modern techniques to implement features that might not be supported in older browsers, I absolutely believe a website doesn’t have to look the same in every browser, and I am absolutely in favour of dropping features for browsers that don’t play nicely, if it is feasible and not to the detriment of the user. What I am not in favour of is this current trend of developers deciding what is ‘feasible’ and what is not, and resorting to deriding their customers, or worse, if their views are not shared.

By far the most popular of any of my personal projects is Flickrshow, a Javascript slideshow that evolved from earlier gallery projects into the first public version in 2006. For those unfamiliar with the project, the goal is to allow as many people as possible to embed a slideshow displaying Flickr images into a webpage. The emphasis has always been on simplicity and ease of use, rather than complex features, and this has led to its use by scores of people who most likely would have resorted to poorer implementations or worse, none at all.

After a hiatus of over a year, I recently released the newest version of Flickrshow to public beta testing. The previous version had no real faults, other than a few glaring feature omissions, but was definitely showing its age. The goal of this new version was to add a few of the most requested features and, more importantly, remove another level of complexity by removing any framework dependance from the slideshow, (it was previously using the Prototype framework).

This version of Flickrshow uses only native Javascript functions, and contains its own animation and remote loading functionality. It now features auto-play, configurable pop-up controls, better themes, multiple shows per page and improved integration with Flickr. It is also compatible with all modern browsers, (although by making use of certain CSS properties it will look slightly less rounded in older software) and the size of the script has been reduced from 58Kb to 8kb. If you are interested in the project, please try out the new version and register any issues.

An old but fascinating article from Information Architects on how contrasts in culture between Japan and the West are exhibited in Apple’s Get A Mac advertising campaign.

Last Sunday, they started airing the […] ads here in Japan. And here’s a surprise: they’re different. The Mac guy isn’t particularly cool and the PC guy is a real “salary man” type. The ads aren’t as obvious as the Western originals. In Japan, you need to be more subtle.

As a newcomer to Japan, and to the social interactions that occur while living and working here, this contrast to the West is impressed upon me every day. Even such fundamental components of Japanese culture, such as the language and it's idioms, exemplify this difference – in my studying of Japanese I am constantly learning new methods of conveying an opinion in a manner which is understood and recognised but not offensive or belittling. For a grumpy gaijin like me it is almost as hard as the language itself.

Something I and those close to me have known for a while, but that hasn't been mentioned on my personal site, (bizarrely)—today is my last day in charge of the technical team at Outside Line. From next week, I will be fulfilling a massive ambition of mine by moving to Japan to live and work. I’ve been Technical Lead at Outside Line for over two years, and have been fortunate to work with some of the most talented and creative designers and developers you are ever likely to meet—we’ve put together some brilliant websites in that time, and I am really proud of the work I’ve been a part of.

From September, I will be taking up the role of UX Engineer with Cirius, where I will be helping to develop and extend their products in the international market. I’m really looking forward to working with some very talented people in a fresh, agile environment, and all within a city as vibrant and exciting as Tokyo. See you all on the other side.

I've recently been developing a little something in Codeigniter that features an API that is as true as possible to the principles of REST. In order to do this, I had to extend the core Codeigniter Input library to allow access to properly escaped values from DELETE or PUT input in the same way as you would normally access GET/POST input.

The code is pretty simple, and unfortunately does require file_get_contents until I can figure out an alternative way of accessing the input. The whole class can be downloaded here.

Recently, we at Outside Line launched a new website for Golden Wonder’s new noodle brand, The Nations Best. In a departure from the normal day-to-day, I built the bespoke server-side functionality to power the nifty Flash front-end. In doing so, I put together a few PHP libraries, one to access the Flickr API and one to access the Host IP geolocation service API.

Both classes, being built at the same time, have a similar structure and similar functionality. They both feature a cache mechanism to limit your requests and enhance performance, and the both are pretty open ended in what they allow you to do. The Flickr class allows access to any method that doesn't require authentication, and returns the results as a PHP array, (in the same format as the original Flickr response).

The Host IP class is slightly more limited, but is easy to extend if more information is required. The results are obtained form a parsed XML response, and contain information outside of the latitude, longitude, city and country. Because of the way in which SimpleXML handles the name spaces, there is also bit of hacking in place to parse the XML.

You can download the Flickr and Host IP class, and they are both offered freely but with no support or guarantee.

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 to 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 agencies. If you are interested, email your CV/portfolio to bens@outsideline.co.uk.