Den Odell

Just as I post recommending the seriously great Firefox plug-in ‘Dust-Me Selectors’, a tool for parsing CSS live in the browser and showing which styles are and aren’t being used (ideal for a sitewide tune-up), version 2.0 gets released:

http://www.sitepoint.com/dustmeselectors/

Seriously recommended.

Testing your web pages during the development process is an absolute must, and isn’t something that should be left to your company’s QA/Testing department. Those guys should be treated as the final hurdle before launch, the ones that test for the most extreme edge cases and conditions.

Each aspect of the page, be it (X)HTML, CSS, JavaScript or plug-ins (Flash, Silverlight, etc.), need validating (theory) and browser testing (real-life). It goes without saying that the markup should be built according to W3C standards, choosing the correct tags for the context, and using as little markup as possible.

Validation
Validate your (X)HTML and CSS against the standards definitions provided by W3C. Your (X)HTML page should specify a DOCTYPE definition as the first line of the file, this will tell the validator which particular definition to test the rest of the page against. Using the right DOCTYPE will also switch browser rendering between ‘standard’ and ‘quirks’ mode. May I suggest ‘standard’ mode

You need to use these two validators:

• (X)HTML Validator
• CSS Validator

Browser testing
It’s useful to have as many browsers as possible installed on your machine for testing.

Here’s what you should install as a minimum on a Windows-based PC:

• Internet Explorer 7
• Internet Explorer 3 – 6 (These days I would argue you only really require IE6)
• Firefox
• Safari
• Opera

On a Mac, I would recommend Firefox, Safari and Opera. Internet Explorer on the Mac is deader than a dodo, and unless you know your end-user base are users, I would only give it a cursory glance.

Now, that’s good enough to view your page in different browsers, but how do you debug the CSS and JavaScript differences appearing between the different browsers?

For JavaScript, it’s always useful to build your own code on top of a base library of cross-browser tested code. I regularly use MooTools for this, as I often use it for its other functionality too, and you can select which portions of the code you wish to download to suit your needs. Choosing a decent base library will help ensure your code works well across most browsers without having to invest much time coding for the differences yourself (it’s always useful to know about these differences, however).

Here’s a list of some browser plug-ins that can be used for debugging, and some useful built-in functionality I’d recommend for each browser:

• Internet Explorer
• Microsoft’s IE Developer Toolbar
• Firefox
• Firebug – THE debugging tool, master this!
  
• YSlow plug-in for Firebug – tips from Yahoo on how to increase performance on your pages (includes JSLint for verifying your JavaScript)
• Chris Pederick’s Web Developer Toolbar – lots of tools and information about your page
• DustMeSelectors – shows which CSS styles are/are not applied on a page (useful to strip out unused styles)
• Safari / Webkit
• The built-in debug menu – this is switched off by defult
• Opera
• Built-in JavaScript console

Feel free to suggest any more in the comments…

Take a look at this website registration form: http://getsatisfaction.com/people/new . Fairly standard stuff.

But look on the right hand side of the page and you’ll notice you can pre-populate the registration form with the data you’ve entered already for your profile on another site (e.g. Flickr, last.fm, and others). All you need to enter is your username for that other site and all the data is dragged out of it and onto this registration form.

How it works: the hCard microformat is a way of encoding a vCard (the standard for address book entries) as standard HTML. Because the hCard microformat defines the structure, it should always be the same from site-to-site. Meaning, as long as a site encodes a user’s profile in this format, we can extract it from a page on their site and know what data we’re getting.

I don’t know how this washes with regards to data protection and the law, but it’s certainly an interesting technique that could save the end user some time filling out a form.

Well, hello there. My name is Den Odell. What’s yours?

I work for a digital media company called AKQA in London, UK, where my job role is ‘Presentation Technical Architect’. I’ve been at the company for over five years, working my way up from Web Developer, through Senior Web Developer to Lead Web Developer, and into my current role.

Rather than a reference to MS PowerPoint, the ‘Presentation’ part of my job title actually refers to the presentation layer, or ‘front-end’, of the web sites and software AKQA produces. Essentially, my job is to define best practice, engineer solutions to some human interface problems and generally help out on a technical level with everything the end user sees and gets to interact with. Historically, this has been pretty much restricted to manipulating XHTML, CSS and JavaScript, but these days things are changing…

Since acheiving my first class BEng degree (sorry, I’m showing off a bit) in Electronic and Electrical Engineering (Communications Systems) at Brunel University in 2000, my working history has been largely in the realm of front-end web development and integration with back-end software and solutions. I do also have some experience with coding ASP.NET / C#, PHP, and other little bits here and there.

I created this blog to spew forth some of my thoughts and contribute some solutions to front-end issues I’ve been facing.

I hope you’ll enjoy reading it.
Den