Skip to main content

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

ChangeWho is affected
{ type: X } wrapper removedConfigs using { "value": { "type": "Int" } }
attrs option deletedConfigs using the deprecated attrs option
Object format deprecatedConfigs using object format for allowAttrs / disallowAttrs
Newly flagged values in v5Any project — new validations fire on existing markup

{ type: X } wrapper removed

Breaking Change

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"
}
]
}
}
}
note

{ enum: [...] } and { pattern: "..." } formats continue to work as before. Only the { type: X } wrapper is removed.

attrs option deleted

Breaking Change

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 allowAttrs as an array
  • Attributes with "disallowed": true go into disallowAttrs
  • Attributes without a value constraint can be specified as a plain string (e.g., "x-data")

Object format deprecated

Deprecation Warning

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

Behavioral change (no config action required)

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.

AreaExample that now failsIssueSpec
input[value] by type<input type="color" value="red">#3598HTML LS — the input element
link[as] by rel<link rel="preload" as="audio">#3189HTML LS — the link element
img[role] + alt=""<img role="presentation" alt="">#3641ARIA in HTML — img
URL forbidden code points<a href="http://example.com/ ">#3629URL LS — URL code points
meta[content] by http-equiv<meta http-equiv="refresh" content="garbage">#3734HTML 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.