Nu Html Checker

Extras

Steve Faulkner has created the following bookmarklets you can use in conjunction with the Nu Html Checker.

• Check serialized DOM of current page: grabs the serialized DOM of whatever page you’re currently browsing and sends it to the checker
• Check serialized DOM of current page (results as JSON): same as above but returns the results from the checker as JSON
• Check for WCAG 2.0 parsing compliance: filters checker results to just show messages relevant to requirements in the WCAG 2.1 spec

Inswave have created the W3C Markup Validation Service for CSR pages, an extension for Chrome and Edge:

• in the Chrome Web Store
• in the Edge Add-ons Store

Reporting issues

To report bugs, request new features, or ask questions, please raise an issue or send mail to www-validator@w3.org.

How to to run your own copy of the Nu Html Checker

To run your own copy of the Nu Html Checker, get the latest release and read the following instructions on how you can use it both for:

• web-based checking of documents
• batch-checking of documents from the command line and from other scripts/apps

Alternatively, consider automating your HTML checking with a frontend such as:

• Grunt plugin for HTML validation
• Gulp plugin for HTML validation
• HTML5 Validator Integration for Travis CI (auto-check documents pushed to a github repo)
• LMVTFY: Let Me Validate That For You (auto-check HTML of JSFiddle/JSBin etc. links in github issue comments)

Why validate?

The core reason to run your HTML documents through a conformance checker is simple: To catch unintended mistakes—mistakes you might have otherwise missed—so that you can fix them.

Beyond that, some document-conformance requirements (validity rules) in the HTML spec are there to help you and the users of your documents avoid certain kinds of potential problems. To explain the rationale behind those requirements, the HTML spec contains these two sections:

• rationale for syntax-level errors
• rationale for restrictions on content models and on attribute values

To summarize what’s stated in those two sections:

• There are some markup cases defined as errors because they are potential problems for accessibility, usability, interoperability, security, or maintainability—or because they can result in poor performance, or that might cause your scripts to fail in ways that are hard to troubleshoot.
• Along with those, some markup cases are defined as errors because they can cause you to run into potential problems in HTML parsing and error-handling behavior—so that, say, you’d end up with some unintuitive, unexpected result in the DOM.

Validating your documents alerts you to those potential problems.