- Getting Started
- Rules categories
- AMP HTML Validator
- Accessibility assessment with aXe
- Avoid HTTP redirects in requests
- Disallow certain HTTP headers
- Disallow non-standard file extension for the web app manifest file
- Disallow protocol-relative URLs
- Disallow small error pages
- Disallow unneeded HTTP headers for non-HTML resources
- HTTP Cache
- Image optimization with Cloudinary
- No vulnerable libraries
- Nu HTML Test
- Performance budget
- Require `Content-Type` HTTP response header with appropriate value
- Require `Strict-Transport-Security` response header
- Require `X-Content-Type-Options` HTTP response header
- Require a web app manifest file
- Require an apple touch icon
- Require charset meta tag with the value of `utf-8`
- Require external links to disown opener
- Require highest available document mode
- Require manifest to specify the web site/app name
- Require resources to be served compressed
- Require scripts and styles to use subresource integrity
- Require viewport meta tag with proper value
- SSL Server Test
- Validate `Set-Cookie` Header
- further configuration
html-checker validates the markup of a website against the
Nu HTML checker.
Serving valid HTML nowadays have been commonly overlooked these days. By running the HTML documents through a checker, it’s easier to catch unintended mistakes which might have otherwise been missed. Adhering to the W3C’s standards has a lot to offer to both the developers and the web users: It provides better browser compatibility, helps to avoid potential problems with accessibility/usability, and makes it easier for future maintainance.
This rule interacts with this service via
and is able to test both remote websites and local server instances.
According to the Nu Html checker documentation, the positive cases contain two sections:
Markup cases that 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.
Markup cases that 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.
For explanation behind those requirements, please checkout:
- rationale for syntax-level errors
- rationale for restrictions on content models and on attribute values
By default only the first occurance of each error/warning is reported when validating the markup. However, you can configure the rule to view the complete list.
The following rule configuration in the
file will enable the full-list view of errors/warnings reported by the
You can ignore certain error/warning by setting the
html-checker rule. You can either pass in a string or an
array that contains all the messages to be ignored.
E.g. The following configuration will ignore the errors/warnings with
the message of
Alternative, you can pass in an array if you have more than one type of messages to ignore:
You can also override the default validator by passing in the endpoint of an alternative validator. However, you need to make sure that this alternative validator exposes the same REST interface as the default one.