When I worked at The Guardian, before committing code to Subversion, unit tests were run against the Java codebase. This is pretty standard. Sometimes, things slipped through and were caught at the Continuous Integration stage where an automated build would perform deeper tests and verify the code integrations of each developer hadn’t broken anything. This approach works extremely well.

When it came to the front-end, the only tests that were run was pushing JavaScript code through JSLint. This wasn’t set up as a pre-commit hook. Rather, it was up to the developer to execute a command-line script that performed these tests. I am in no way complaining about this. It was the first and only place I have worked that actually bothered to set up any formal testing of front-end code.

A few months ago I went to a presentation given by Neil Crosby at Skills Matter. Neil spoke about a project he has been working on that addresses the lack of automated frontend testing.

Most web developers will occassionally validate HTML and CSS, and put their JavaScript through JSLint. If this were automated, a lot of time would be saved. Some bugs can take hours to fix and in the end, for example, all that was missing was a closing span tag in the HTML.

Neil’s come up with a framework, called Frontend Test Suite, that automatically runs frontend code through the above tools. The suite is built in PHP and it is recommended that you install local copies of the HTML Validator, CSS Validator and JSLint so your IP doesn’t get banned.

I followed Neil’s installation steps in the file SETUP, which are briefly listed here:

1. Installed PHP (didn’t really because it’s already installed with Mac OS X 10.5.7
2. Installed PEAR
3. Installed PHPUnit
4. Downloaded Frontend Test Suite
5. Installed HTML Validator locally
6. Installed CSS Validator locally (thanks Jen)
7. Installed Rhino
8. Downloaded JSLint.js

I use Aptana regularly so, alongside the project I’m currently working on, I created a new project, dumped the Frontend Test Suite files into it and made the necessary edits to the example file. I execute the tests via the command line but at some point I will set up Aptana so I can execute it from there.

Next I need to workout how to get subversion to run these tests pre-commit.

---

Posted by Nick on May 29th, 2009 :: Filed under css,development,html,javascript

---

Ian Hickson, the editor of the HTML 5 specification, was interviewed by Bruce Lawson earlier this month. Ian listed a few things we can look forward to in HTML 5:

Long term, content authors will find a variety of new features in HTML 5. We have a bunch of new structural elements like section, article, footer, and so on. We have new elements for embedded media, like video and audio. We have new input controls, like the calendars I mentioned, but also fields for URLs, e-mail addresses, telephone numbers, and for color selection. We have control over autocomplete values in text fields, as well as field validation so that you can say which fields are required. We have context menus, pushState() so you can update the URL in Ajax applications, and offline application cache manifests so that your users can take your applications offline. The list goes on.

Ian expects the HTML 5 spec to be in its final stages by October 2009. Browser vendors have already started to include support for some HTML 5 elements, e.g. the video and audio elements. As Ian points out in the interview, browsers, which are constantly evolving, are an implementation of the spec, and will never be HTML 5. A browser’s implementation will only ever be a subset or superset of HTML 5.

HTML 5 will make life as a web developer much simpler. Field validation on its own reduces a great deal of complexity. With the inclusion of ARIA attributes too, the web will become much richer and more accessible to all over the coming years. Talking about evolution in the browser world always brings one back to the same question – how to deal with IE6′s refusal to die? I like Andy Clarke’s idea about Universal Internet Explorer 6 CSS. Day by day I sense I am coming closer to the momentus event of a client saying “don’t worry about IE6″. Supporting an 8 year old piece of software is a nonsense and soon the tide will turn, before the end of the 2009 I hope. Budgets will shift from supporting the lowest common denominator to growing technologies like the proven appetite for mobile web applications, I hope. My path to insanity will stop then, I hope.

I think working in the web development industry, which is unique in that it spans all work sectors, will soon start to get exciting again. Accessibility doesn’t have to be a reason to stifle creativity, although ARIA isn’t a fix for all issues so diligence is still required. And functionality will not need to be hampered anymore because of the limitations of an 8 year old browser. I’m writing from the perspective of a web developer who attempts to make websites that are inclusive for all users. I know there has been a great deal of innovation in the industry, pushing the boundaries with JavaScript, Flash, Silverlight, etc… But making use of these technologies and trying to remain accessible to all is a very expensive business. Budgets are never big enough.

The sooner HTML 5 is baked into browsers, the sooner screen reader users upgrade to WAI-ARIA compatible screen reader software, the sooner corporate IT departments drop IE6, the better the web will be for all, I hope.

---

Posted by Nick on May 22nd, 2009 :: Filed under accessibility,ie6

---