Roadmap

Currently html-validate internally maintains a list of allowed usages of aria-label. This list is hard to maintain and is currently a big source of incoming issues.

The goal of this issue is to start using the @html-validate/w3c-data package which scrapes the metadata from the standards directly.

• Update all rules related to aria-label to use metadata from this package.
• Add a configuration to enable the user to specify which version of the ARIA standard to use.

Currently html-validate only validates attributes it knows about. It should also yield errors when unknown attributes are encountered.

Many rules report errors which could be fixed automatically.

When a rule reports and error/warning it should optionally provide a list of:

• fixes: definitive solutions to the issue
• suggestions: possible solutions to the issue
• each entry should include a callback to run including the Source object, helper functions.

The difference between the two is that a suggestion might not always work or provide a more opinionated solution.

The CLI should support a --fix option which would apply the first fix (not suggestion). Tooling such as the vscode extension should show the full list and leave it to the user which one to apply.

Currently the CLI runs everything in serial on the same thread (main), work is in progress to offload the validation to workers and let the CLI run multiple workers in parallel.

The gist of the required changes:

• Create and run CLI workers running the actual validation
• New --workers option to control number of workers.
• Offload both configuration loading and validation to workers.

The preference would be if the main thread holds the full queue of files to validate and dispatching jobs once a worker is free, in contrast to just splitting the queues into equal sized chunks. The rationale is that some jobs takes much longer.

Note: only the CLI will be parallelized, user of the API will have to implement this themselves if needed.

The VSCode extension often gives error messages for conditions outside of its control, e.g. if the project package.json is malformed during a merge conflict.

We should try to categorize the errors that may happen:

• Errors from bugs in the extension
• Errors from html-validate (internal errors)
• Configuration errors in the users environment
• Other environmental issues preventing the extension from running

All of these should be handled separately and not all show the scary "The extension crashed" message.

The current documentation site is in need of a complete overhaul, to improve visuals, functionality and content.

This epic tracks the requirements and progress of the new site.

The site should prefer native solutions over javascript, progressive enhancements if needed but anything with javascript should be added with good reason. Native elements/techniques > CSS > Javascript.

Right now the parser stops as soon as any tokenization error occurs, even if a recovery would be possible. Sometimes the HTML standard defines the recovery procedure, sometimes we could recover by inserting or removing a known character.

The parser errors should still be reported and should not be ignorable (with directives) or configurable (neither enabled or disabled).

But with the recovery means that the rest of the document can be validated properly.