Frontend Web – How to validate the second class languages

Let’s be honest. We say we treat JavaScript and CSS with care and respect. But most of the time it’s a lie. There is no ‘compilation’, just interpretation, and browsers aren’t as consistent as any JVM. They are fragile at the best of times. So we shouldn’t bother validating them, or creating style guides… right?

Wrong. If you’re developing in Java, you are probably using Eclipse of Intellij. You compile your code, and usually each team has a specific formatter/style guide everyone uses. With jS/CSS it’s open season. The best you can hope for is the Aptana Eclipse editors, which alleviate some of the pain.

I’ve been looking for different way to validate CSS to to some kind of standard. It’s hard as although there are defined specs by the W3C many browsers use their own or have their own -moz or -webkit extensions.

The W3C site has it’s own CSS validator, but it’s online and we don’t want to depend on (or thrash) an external service.

I looked at running this locally – one thing that bothered me is the amount of mucking around with the build.xml to get the damn thing to build with ant.

Anyways, there were about 6 missing dependencies in the build.xml so i’ve fixed them and will submit a patch.

It seems the Apache libraries are the culprits. Velocity, Xerces, Apache Commons and Apache Lang have all had older versions removed from their HTTP links on the master website, and it can’t be limited to just this utility i’ve looked at within 24 hours.

Maybe Apache finally decided to ‘force’ people to update their dependencies. People often moan about this breaking apps they have been using, but as a developer it is a risk to rely on a version that isn’t supported any more.

One thing I love about GitHub is the ability to submit pull requests. It takes the blame/flame game and turns it on it’s head into a constructive addition people can make to open source libraries. Everyone wins.

In case you are trying to build the W3C CSS Validator, see this obscure issue listed on their BugZilla issue tracking site in the form of a patch to build.xml: http://www.w3.org/Bugs/Public/attachment.cgi?id=1007&action=edit

I have created my own (working) zip of the CSS validator you can run locally (requires JRE). I will provide a link here shortly.

I also looked at CSSLint, which is written in JavaScript. You can run it via Rhino (Java-based JavaScript engine) or Node (much faster). It doesn’t really validate properties, mainly looks for bad semantics and highlights them. It can handle browser extensions to CSS styles.

While i’m at it, I highly recommend JSHint.
This is a fantastic, forked improvement over Doug Crockford’s JSLint (which is showing its age now). Every project is different and having the ability to turn on and off varying levels of strictness is important.

Integrate this into your build and you will save yourself hours of pain down the track.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s