Nu Html Checker
The Nu Html Checker (v.Nu) is an ongoing experiment in better HTML checking, and its behavior remains subject to change. In particular, because new types of error checks continue to be actively added to the checker, there is no guarantee provided that if the checker reports zero errors for a particular document at one point in time, it will report zero errors for that same document at some later point in time.
The Nu Html Checker should not be used as a means to attempt to unilaterally enforce pass/fail conformance of documents to any particular specifications; it is intended solely as a checker, not as a pass/fail certification mechanism.
Extras
- «;break;case Node.COMMENT_NODE:b+ +a.nodeValue+»—\>»;break;case Node.DOCUMENT_TYPE_NODE:b+ +a.name+»>\n»>a=a.nextSibling>return b>(document),d=document.createElement(«form»);d.method=»POST»;d.action=»https://validator.w3.org/nu/»;d.enctype=»multipart/form-data»;d.target=»_blank»;d.acceptCharset=»utf-8″;c(«showsource»,»yes»);c(«content»,e);document.body.appendChild(d);d.submit()>)();’>Check serialized DOM of current page: grabs the serialized DOM of whatever page you’re currently browsing and sends it to the checker
- «;break;case Node.COMMENT_NODE:b+ +a.nodeValue+»—\>»;break;case Node.DOCUMENT_TYPE_NODE:b+ +a.name+»>\n»>a=a.nextSibling>return b>(document),d=document.createElement(«form»);d.method=»POST»;d.action=»https://validator.w3.org/nu/»;d.enctype=»multipart/form-data»;d.target=»_blank»;d.acceptCharset=»utf-8″;c(«showsource»,»yes»);c(«out»,»json»);c(«content»,e);document.body.appendChild(d);d.submit()>)();’>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
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:
- 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.
Не лайтхаусом единым: как проверить свой сайт со всех сторон
Когда мы говорим о веб-валидаторах и оптимизации сайта под них, мы чаще всего имеем ввиду Lighthouse/Pagespeed Insights от Google, который давно стал де-факто стандартом для оценки производительности сайта. Кто-то стремится к заветным 100 баллам даже на прототипах и шаблонных приложениях в две кнопки, кто-то в шутку создает абсолютно недоступный сайт с идеальным рейтингом, но для всех фронтендеров лайтхаус предоставляет вменяемую, хоть и довольно поверхностную, аналитику производительности сайта и поиск бутылочных горлышек. Однако скорость загрузки — лишь один из множества параметров, которые стоит проверять на своём сайте, и для большинства других есть свои валидаторы и скоринговые алгоритмы. Мы рассмотрим инструменты для каждого из значимых направлений и составим список, по которому стоит прогонять свой сайт, чтобы в дальнейшем не отлавливать проблемы вручную.
На что мы будем обращать внимание?
Разбивка на категории может быть у каждого своя, мы возьмём следующую:
Производительность, об неё уже достаточно сломано копий- Доступность, идущая следом по важности
- Чистота и качество кода
- Сетевые проверки
- SEO и остальное
Доступность
Главная головная боль разработчика после скорости загрузки — обеспечить пользователям всех групп удобное взаимодействие с сайтом. Всё просто, достаточно следовать WCAG (Web Content Accessibility Guidelines), расставлять альтернативный текст для картинок, форм и иконок, следить за читаемостью страницы со скринридера, соблюдением i18n и кучи других вещей из стандартов w3, которые невозможно удержать в голове, но важно не забывать в вебе.
Web Accessibility Evaluation Tool
WAVE это комплексный инструмент, показывающий косяки в контрасте, alt-ах, ярлыках для форм, очерёдности заголовков и aria-свойствах. Работает в браузере, показывает в превьюшке все проблемы:
Automated Accessibility Testing Tool
AATT от PayPal — всесильный комбайн, стандартный инструмент валидации для кучи крупных компаний. Работает не только с вебом, потому и сидит на локалхосте, умеет общаться по API с другими серверами на вашей машине.
Axe by Deque
Axe входит в состав AATT, но также доступен в виде отдельного расширения для Chrome. Подойдёт для быстрой проверки уже выверенного продукта. Вообще у него довольно крутая экосистема, которой пользуются такие гиганты как Google и Microsoft.
Вышеупомянутые гайдлайны сами по себе не инструмент, но в виде чеклиста тоже удобны. Некоторые печатают их себе на стену и сверяются на ходу.
Тут важно вспомнить что все эти валидаторы — обычные алгоритмы, которые могут ошибаться и в 90% случаем найдут за что вас прищучить. Просто обращайте внимание на свои косяки и игнорируйте косяки программные.
Nu HTML Checker
Nu — удобный HTML валидатор от W3C с подробными предупреждениями и проверкой многих неочевидных правил:
CSS Validator
Как следует из названия, подробный валидатор CSS от W3C, аггрегирует ошибки и вываливает целые тонны предупреждений, которые просто невозможно взять и пофиксить в один заход.
CSS Stats
Офигенный сервис, наглядно разбирающий ваш CSS на части. Покажет в порядке использования все цвета, кегли, гарнитуры, посчитает все свойства, отступы, z-индексы и вообще поможет справиться с лапшеобразными стилями:
i18n Checker
Этот чекер покажет используемые языки, проверит содержимое соответствующих тегов и заголовков. Нужен редко, но полезен.
Rocketvalidator
Сервис действительно очень быстро анализирует HTML и CSS, но скоринг ещё не доделан.
Сеть и ссылки
Link Checker
Крутой чекер от W3C, документирует коды ответа и собственно проблемы со всеми ссылками, до которых может дотянуться при заданной глубине рекурсии
Проверка оптимизации для мобильных устройств
Этот гугловский портал показывает недогруженные ресурсы и отображает загружаемый роботами контент.
Pagewatch
Достойный подражатель Lighthouse, который тоже умеет проверять целостность ссылок. Вообще много чего умеет и также даёт аналитику по всем слабым местам и прелагает аккуратный скоринг.
SEO и прочее
Browseo
Инструмент, показывающий сайт с точки зрения поисковых ботов.
Majestic report
Статистика с кучей графиков по трендам и темам.
Sitecheck
Лёгкий аудит безопасности со своим скорингом и мониторингом чёрных списков/скама/спама. Ищёт уязвимости и предлагает решения:
Favicon Check
Этот инструмент проверит наличие и совместимость иконок сайта для всех платформ, включая мобильные иконки для PWA.
Заключение
Конечно, это не все возможные полезные чекеры, но все они полезны и облегчают ручную работу разработчику. Можно расмотреть ещё больше инструментов для анализа безопасности, сетевых маршрутов и SEO, но это всё-таки скорее узкопрофильные задачи, которые простые веб-сервисы выполнят плохо. Если у вас есть любимый инструмент для валидации или скоринга, который мы не упомянули — расскажите о нём в комментариях.
На правах рекламы
Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент 🙂 Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость.
The Nu Html Checker (v.Nu)
A Dockerfile (see Pulling the Docker image below) and npm, pip, and brew packages are also available.
It is released upstream in these formats:
pre-compiled Linux, Windows, and macOS binaries that include an embedded Java runtime
vnu.jar — a portable version you can use on any system that has Java 8 or above installed
Note: The vnu.jar and vnu.war files require you to have Java 8 or above installed. The pre-compiled Linux, Windows, and macOS binaries don’t require you to have any version of Java already installed at all.
html5validator pip package (for integration in Travis CI, CircleCI, CodeShip, Jekyll, Pelican, etc.)
LMVTFY: Let Me Validate That For You (auto-check JSFiddle/JSBin, etc., links in GitHub issue comments)
Usage
Run the checker with one of the following invocations:
• vnu-runtime-image/bin/vnu OPTIONS FILES (Linux or macOS)
• vnu-runtime-image\bin\vnu.bat OPTIONS FILES (Windows)
/vnu.jar OPTIONS FILES (any system with Java8+ installed)
…where FILES are the documents to check, and OPTIONS are zero or more of the following options:
The Options section below provides details on each option, and the rest of this section provides some specific examples.
Note: Throughout these examples, replace
/vnu.jar with the actual path to that jar file on your system, and replace vnu-runtime-image/bin/vnu and vnu-runtime-image\bin\vnu.bat with the actual path to the vnu or vnu.bat program on your system — or if you add the vnu-runtime-image/bin or vnu-runtime-image\bin directory your system PATH environment variable, you can invoke the checker with just vnu .
To check one or more documents from the command line:
Note: If you get a StackOverflowError error when invoking the checker, try adjusting the thread stack size by providing the -Xss option to java:
To check all documents in a particular directory DIRECTORY_PATH as HTML:
More examples
Note: The examples in this section assume you have the vnu-runtime-image/bin or vnu-runtime-image\bin directory in your system PATH environment variable. If you’re using the jar file instead, replace vnu in the examples with java -jar
To check all documents in a particular directory DIRECTORY_PATH as HTML, but skip any documents whose names don’t end with the extensions .html , .htm , .xhtml , or .xht :
To check all documents in a particular directory as CSS:
To check all documents in a particular directory as CSS, but skip any documents whose names don’t end with the extension .css :
To check all documents in a particular directory, with documents whose names end in the extension .css being checked as CSS, and all other documents being checked as HTML:
To check all documents in a particular directory as SVG:
To check all documents in a particular directory as SVG, but skip any documents whose names don’t end with the extension .svg :
To check all documents in a particular directory, with documents whose names end in the extension .svg being checked as SVG, and all other documents being checked as HTML:
To check a Web document:
To check standard input:
Options
When used from the command line as described in this section, the checker provides the following options:
—asciiquotes
—errors-only
—Werror
—exit-zero-always
—stdout
—filterfile FILENAME
—filterpattern REGEXP
—format format
—skip-non-css
—skip-non-svg
—skip-non-html
—also-check-css
—also-check-svg
—user-agent USER_AGENT
—no-langdetect
—no-stream
—verbose
—version
Web-based checking
The Nu Html Checker — along with being usable as a standalone command-line client — can be run as an HTTP service, similar to validator.w3.org/nu, for browser-based checking of HTML documents, CSS stylesheets, and SVG images over the Web. To that end, the checker is released as several separate packages:
Linux, Windows, and macOS binaries for deploying the checker as a simple self-contained service on any system
vnu.jar for deploying the checker as a simple self-contained service on a system with Java installed
vnu.war for deploying the checker to a servlet container such as Tomcat
All deployments expose a REST API that enables checking of HTML documents, CSS stylesheets, and SVG images from other clients, not just web browsers. And the Linux, Windows, and macOS binaries and vnu.jar package also include a simple HTTP client that enables you to either send documents to a locally-running instance of the checker HTTP service — for fast command-line checking — or to any remote instance of the checker HTTP service running anywhere on the Web.
The latest releases of the Linux, Windows, and macOS binaries and vnu.jar and vnu.war packages are available from the validator project at github. The following are detailed instructions on using them.
Note: Throughout these instructions, replace
/vnu.jar with the actual path to that jar file on your system, and replace vnu-runtime-image/bin/java and vnu-runtime-image\bin\java.exe with the actual path to the checker java or java.exe program on your system — or if you add the vnu-runtime-image/bin or vnu-runtime-image\bin directory your system PATH environment variable, you can invoke the checker with just java nu.validator.servlet.Main 8888 .
Standalone web server
To run the checker as a standalone service (using a built-in Jetty server), open a new terminal window and invoke the checker like this:
Then open http://0.0.0.0:8888 in a browser. (To listen on a different port, replace 8888 with the port number.)
Warning: Future checker releases will bind by default to the address 127.0.0.1 . Your checker deployment might become unreachable unless you use the nu.validator.servlet.bind-address system property to bind the checker to a different address:
When you open http://0.0.0.0:8888 (or whatever URL corresponds to the nu.validator.servlet.bind-address value you’re using), you’ll see a form similar to validator.w3.org/nu that allows you to enter the URL of an HTML document, CSS stylesheet, or SVG image, and have the results of checking that resource displayed in the browser.
Note: If you get a StackOverflowError error when using the checker, try adjusting the thread stack size by providing the -Xss option to java:
Deployment to servlet container
To run the checker inside of an existing servlet container such as Apache Tomcat you will need to deploy the vnu.war file to that server following its documentation. For example, on Apache Tomcat you could do this using the Manager application or simply by copying the file to the webapps directory (since that is the default appBase setting). Typically you would see a message similar to the following in the catalina.out log file.
Assuming your servlet container is configured to receive HTTP requests sent to localhost on port 80 and the context root of this application is vnu (often the default behavior is to use the WAR file’s filename as the context root unless one is explicitly specified) you should be able to access the application by connecting to http://localhost/vnu/.
Note: You may want to customize the /WEB-INF/web.xml file inside the WAR file (you can use any ZIP-handling program) to modify the servlet filter configuration. For example, if you wanted to disable the inbound-size-limit filter, you could comment out that filter like this:
HTTP client (for fast command-line checking)
The checker is packaged with an HTTP client you can use from the command line to either send documents to a locally-running instance of the checker HTTP service — for fast command-line checking — or to a remote instance anywhere on the Web.
To check documents locally using the packaged HTTP client, do this:
Start up the checker as a local HTTP service, as described in the Standalone web server section.
Open a new terminal window and invoke the HTTP client like this:
To send documents to an instance of the checker on the Web, such as html5.validator.nu/, use the nu.validator.client.host and nu.validator.client.port options, like this:
Other options are documented below.
HTTP client options
When using the packaged HTTP client for sending documents to an instance of the checker HTTP service for checking, you can set Java system properties to control configuration options for the checker behavior.
Name already in use
Work fast with our official CLI. Learn more about the CLI.
Sign In Required
Please sign in to use Codespaces.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Latest commit
Git stats
Files
Failed to load latest commit information.
README.md
The Nu Html Checker (v.Nu)
A Dockerfile (see Pulling the Docker image below) and npm, pip, and brew packages are also available.
It is released upstream in these formats:
pre-compiled Linux, Windows, and macOS binaries that include an embedded Java runtime
vnu.jar — a portable version you can use on any system that has Java 8 or above installed
Note: The vnu.jar and vnu.war files require you to have Java 8 or above installed. The pre-compiled Linux, Windows, and macOS binaries don’t require you to have any version of Java already installed at all.
html5validator pip package (for integration in Travis CI, CircleCI, CodeShip, Jekyll, Pelican, etc.)
LMVTFY: Let Me Validate That For You (auto-check JSFiddle/JSBin, etc., links in GitHub issue comments)
Run the checker with one of the following invocations:
• vnu-runtime-image/bin/vnu OPTIONS FILES (Linux or macOS)
• vnu-runtime-image\bin\vnu.bat OPTIONS FILES (Windows)
/vnu.jar OPTIONS FILES (any system with Java8+ installed)
…where FILES are the documents to check, and OPTIONS are zero or more of the following options:
The Options section below provides details on each option, and the rest of this section provides some specific examples.
Note: Throughout these examples, replace
/vnu.jar with the actual path to that jar file on your system, and replace vnu-runtime-image/bin/vnu and vnu-runtime-image\bin\vnu.bat with the actual path to the vnu or vnu.bat program on your system — or if you add the vnu-runtime-image/bin or vnu-runtime-image\bin directory your system PATH environment variable, you can invoke the checker with just vnu .
To check one or more documents from the command line:
Note: If you get a StackOverflowError error when invoking the checker, try adjusting the thread stack size by providing the -Xss option to java:
To check all documents in a particular directory DIRECTORY_PATH as HTML:
Note: The examples in this section assume you have the vnu-runtime-image/bin or vnu-runtime-image\bin directory in your system PATH environment variable. If you’re using the jar file instead, replace vnu in the examples with java -jar
To check all documents in a particular directory DIRECTORY_PATH as HTML, but skip any documents whose names don’t end with the extensions .html , .htm , .xhtml , or .xht :
To check all documents in a particular directory as CSS:
To check all documents in a particular directory as CSS, but skip any documents whose names don’t end with the extension .css :
To check all documents in a particular directory, with documents whose names end in the extension .css being checked as CSS, and all other documents being checked as HTML:
To check all documents in a particular directory as SVG:
To check all documents in a particular directory as SVG, but skip any documents whose names don’t end with the extension .svg :
To check all documents in a particular directory, with documents whose names end in the extension .svg being checked as SVG, and all other documents being checked as HTML:
To check a Web document:
To check standard input:
When used from the command line as described in this section, the checker provides the following options:
The Nu Html Checker — along with being usable as a standalone command-line client — can be run as an HTTP service, similar to validator.w3.org/nu, for browser-based checking of HTML documents, CSS stylesheets, and SVG images over the Web. To that end, the checker is released as several separate packages:
Linux, Windows, and macOS binaries for deploying the checker as a simple self-contained service on any system
vnu.jar for deploying the checker as a simple self-contained service on a system with Java installed
vnu.war for deploying the checker to a servlet container such as Tomcat
All deployments expose a REST API that enables checking of HTML documents, CSS stylesheets, and SVG images from other clients, not just web browsers. And the Linux, Windows, and macOS binaries and vnu.jar package also include a simple HTTP client that enables you to either send documents to a locally-running instance of the checker HTTP service — for fast command-line checking — or to any remote instance of the checker HTTP service running anywhere on the Web.
The latest releases of the Linux, Windows, and macOS binaries and vnu.jar and vnu.war packages are available from the validator project at github. The following are detailed instructions on using them.
Note: Throughout these instructions, replace
/vnu.jar with the actual path to that jar file on your system, and replace vnu-runtime-image/bin/java and vnu-runtime-image\bin\java.exe with the actual path to the checker java or java.exe program on your system — or if you add the vnu-runtime-image/bin or vnu-runtime-image\bin directory your system PATH environment variable, you can invoke the checker with just java nu.validator.servlet.Main 8888 .
Standalone web server
To run the checker as a standalone service (using a built-in Jetty server), open a new terminal window and invoke the checker like this:
Then open http://0.0.0.0:8888 in a browser. (To listen on a different port, replace 8888 with the port number.)
Warning: Future checker releases will bind by default to the address 127.0.0.1 . Your checker deployment might become unreachable unless you use the nu.validator.servlet.bind-address system property to bind the checker to a different address:
When you open http://0.0.0.0:8888 (or whatever URL corresponds to the nu.validator.servlet.bind-address value you’re using), you’ll see a form similar to validator.w3.org/nu that allows you to enter the URL of an HTML document, CSS stylesheet, or SVG image, and have the results of checking that resource displayed in the browser.
Note: If you get a StackOverflowError error when using the checker, try adjusting the thread stack size by providing the -Xss option to java:
Deployment to servlet container
To run the checker inside of an existing servlet container such as Apache Tomcat you will need to deploy the vnu.war file to that server following its documentation. For example, on Apache Tomcat you could do this using the Manager application or simply by copying the file to the webapps directory (since that is the default appBase setting). Typically you would see a message similar to the following in the catalina.out log file.
Assuming your servlet container is configured to receive HTTP requests sent to localhost on port 80 and the context root of this application is vnu (often the default behavior is to use the WAR file’s filename as the context root unless one is explicitly specified) you should be able to access the application by connecting to http://localhost/vnu/.
Note: You may want to customize the /WEB-INF/web.xml file inside the WAR file (you can use any ZIP-handling program) to modify the servlet filter configuration. For example, if you wanted to disable the inbound-size-limit filter, you could comment out that filter like this:
HTTP client (for fast command-line checking)
The checker is packaged with an HTTP client you can use from the command line to either send documents to a locally-running instance of the checker HTTP service — for fast command-line checking — or to a remote instance anywhere on the Web.
To check documents locally using the packaged HTTP client, do this:
Start up the checker as a local HTTP service, as described in the Standalone web server section.
Open a new terminal window and invoke the HTTP client like this:
To send documents to an instance of the checker on the Web, such as html5.validator.nu/, use the nu.validator.client.host and nu.validator.client.port options, like this:
Other options are documented below.
HTTP client options
When using the packaged HTTP client for sending documents to an instance of the checker HTTP service for checking, you can set Java system properties to control configuration options for the checker behavior.