invalid-attr Rule Changes
This page covers breaking changes to the invalid-attr rule options and a set of new values that the default rule now flags — markup that was silently accepted in v4 may surface as errors after upgrading, even with no config changes.
Summary
| Change | Who is affected |
|---|---|
{ type: X } wrapper removed | Configs using { "value": { "type": "Int" } } |
attrs option deleted | Configs using the deprecated attrs option |
| Object format deprecated | Configs using object format for allowAttrs / disallowAttrs |
| Newly flagged values in v5 | Any project — new validations fire on existing markup |
{ type: X } wrapper removed
The { type: X } wrapper object for attribute values has been removed. Specify the type string directly.
Before (v4):
{
"invalid-attr": {
"options": {
"allowAttrs": [
{
"name": "x-count",
"value": { "type": "Int" }
}
]
}
}
}
After (v5):
{
"invalid-attr": {
"options": {
"allowAttrs": [
{
"name": "x-count",
"value": "Int"
}
]
}
}
}
{ enum: [...] } and { pattern: "..." } formats continue to work as before. Only the { type: X } wrapper is removed.
attrs option deleted
The attrs option has been removed. It was deprecated since v3.7.0. Use allowAttrs and disallowAttrs instead.
Before (v4):
{
"invalid-attr": {
"options": {
"attrs": {
"x-data": { "type": "Any" },
"x-count": { "type": "Int" },
"x-color": { "enum": ["red", "blue"] },
"x-id": { "pattern": "/^[a-z]+$/" },
"x-banned": { "disallowed": true }
}
}
}
}
After (v5):
{
"invalid-attr": {
"options": {
"allowAttrs": [
"x-data",
{ "name": "x-count", "value": "Int" },
{ "name": "x-color", "value": { "enum": ["red", "blue"] } },
{ "name": "x-id", "value": { "pattern": "/^[a-z]+$/" } }
],
"disallowAttrs": ["x-banned"]
}
}
}
Key differences:
- Allowed attributes go into
allowAttrsas an array - Attributes with
"disallowed": truego intodisallowAttrs - Attributes without a value constraint can be specified as a plain string (e.g.,
"x-data")
Object format deprecated
The object format for allowAttrs and disallowAttrs still works in v5, but it will be removed in a future version. Switch to the array format now.
Before (object format):
{
"invalid-attr": {
"options": {
"allowAttrs": {
"x-attr": "Int"
}
}
}
}
After (array format):
{
"invalid-attr": {
"options": {
"allowAttrs": [
{
"name": "x-attr",
"value": "Int"
}
]
}
}
}
Newly flagged values in v5
v5 tightens the default invalid-attr coverage in several areas that were previously accepted as Any. If you upgrade without touching your config, the markup below may raise violations it did not in v4.
Each row cites the issue where the validation was introduced and the HTML / URL / Encoding Living Standard section that justifies it. If you hit a new violation you believe is incorrect, read the linked issue first — several of these land with spec-cited excluded-ids.json entries for cases where nu-validator was stricter than the spec.
| Area | Example that now fails | Issue | Spec |
|---|---|---|---|
input[value] by type | <input type="color" value="red"> | #3598 | HTML LS — the input element |
link[as] by rel | <link rel="preload" as="audio"> | #3189 | HTML LS — the link element |
img[role] + alt="" | <img role="presentation" alt=""> | #3641 | ARIA in HTML — img |
| URL forbidden code points | <a href="http://example.com/"> | #3629 | URL LS — URL code points |
meta[content] by http-equiv | <meta http-equiv="refresh" content="garbage"> | #3734 | HTML LS — meta http-equiv |
No config change is needed to opt in; conversely, these stricter checks cannot be rolled back individually. If a specific case breaks your workflow, file an issue with the failing markup and cite the governing spec paragraph — fixes for real spec misreads will be reverted or narrowed.