Skip to content

Monkeybruiser

HTML and CSS Validation: Does it Still Matter?

When I started building websites all those years ago, I tried my hardest to ensure my production code was fully validated using online services such as HTML5 validator and CSS Validator.

Meticulously running my code through the validator made it seem like I was doing a better job when I finally got the green tick and launched the site.

It’s been a long time since I last got that green tick.

Over the years my stance on having the code fully validated has gradually turned to nonchalance until recently launching a new website.

The validators have long been part of my go live process but I found myself paying less attention to the ‘warnings’ and ‘errors’ due to the advances in both HTML and CSS and the less likely chance the validators had updated quickly enough to know what was considered ‘good’ and ‘bad’.

I currently use Gulp and PostCSS to compile and compress my JS and SCSS and could pretty much guarantee that the final CSS file would fail, big time, in the validator. The question I found myself asking when I was greeted with the validator’s red screen of failure was; Do I even care?

A silly question, really, because of course I care. Really, the questions should have been ‘What can I do about it?’.

The SCSS is well written (as far as I can tell anyway) and the resulting file size of the CSS is pretty small. It works across as many browsers and devices as I could test and looked great, not to mention very close to the original designs of the site despite the tweaks and changes made with the client along the way. Surely that’s the best outcome I could have hoped for?

This question has been pretty well documented over the last few years – See Zurb’s 2013 blog post here for example – but it’s not something I’ve really thought about until now.

I won’t be removing the step from my go live process any time soon, so maybe I should start checking off those warnings again…