Question About Front-end Validation

Sherpa Chris Casciano answers:

There was a time, in the not so distant past, when one of the first rules for coding HTML was to run your page through W3C’s Validation Service. Primitive editing tools and nascent browser engines of the time often led to markup errors which, in turn, caused varied and sometimes dramatically different page errors. Missing closing tags or improperly nested elements could be benign in one browser, but a fatal flaw in others. As a result, validation became our best defense against unpredictable rendering.

Our industry has since moved on from “writing HTML pages” to developing more complex ecosystems with JavaScript DOM manipulation, CSS inheritance and transitions, and template and CMS tools, all of which can make validation errors apparent as we build our code. This, combined with how the HTML5 specification has standardized browser error handling, means we’re now in a position where markup is very predictable and consistent, and errors are more obvious upon first glance.

So what is the current role of validation? Consider Postel’s Law:

Be liberal in what you accept, and conservative in what you send

Validation, or rather it’s goal of enforcing valid syntax and coding rules, is still at the heart of what we do. With the complexity of modern sites, and the reliance on document manipulation in the browser, it may be even more important to make sure the code you write (or is generated on your site) is accurate.

Fortunately, code validity (and its siblings strictness and linting) can be checked and with many different tools, both passively and aggressively. Today’s tools make it easier than ever to enforce validation rules and output valid syntax, not just for HTML, but also for JavaScript and CSS.

Compilation and Preprocessors

With the prevalence of automated tools for deployment, code minification and preprocessing, valid code is often required long before anything ever hits a browser. For example, try writing invalid CSS in this live SASS demo or outputting JS with syntax errors via CoffeeScript. These preprocessors simply won’t output final code when they encounter syntax errors.

JavaScript Strict Mode

You can also opt-in to browsers that use a more restrictive strict mode for parsing and executing JavaScript. Simply add the use strict; statement to your JavaScript code.

Dig more into strict mode with this article from Sherpa Author Nicholas Zakas: It’s time to start using JavaScript strict mode.

Linting

Linters are code quality tools that scan code for bad coding practices such as undeclared variables, overly complex selector usage or bad coding styles. They are often quite opinionated about the coding style guidelines they check against, but can be tweaked to fit your own coding styles. If their opinions align with yours they’re great tools.

• JSLint and JSHint for JavaScript
• CSSLint for CSS

Validation Services

If you just want to validate your code, the W3C maintains their validation services for markup validation and CSS validation, and are building a new automated testing suite.

Browser add-ons like Chris Pederick’s Web Developer can make it easier to upload your page’s code to these W3C services, even from hidden development environments or your local computer.

Additional Resources

• Many of the above tools can be automated via workflow tools such as Grunt and Yeoman, or as tasks in automated testing frameworks.
• Your favorite code editor (such as Sublime Text, Texmate, or Coda) will have bundles or add-ons to validate and lint your code.
• The developer tools found in your browsers will often report on validation or other errors, and provide additional analyzation and debuggings tools.
• Other tools are also available to analyze your site for good coding practices such as performance, accessibility or structured data.