ember-template-lint
Advanced tools
Changelog
v0.5.12
Change nested-interactive
rule to ignore elements using tabindex
when determining if a parent element is interactive. tabindex
is still used
for detecting all child elements once already inside of another interactive element.
Fix various issues with nested-interactive
and <label>
.
<label>
an interactive element.<label><input></label>
.<label>
.Fix bugs with the invalid-indentation
around escaped mustaches and raw blocks.
Add invalid-interactive
rule (full documentation).
Adding interactivity to an element that is not naturally interactive content leads to a very poor experience for
users of assistive technology (i.e. screen readers). In order to ensure that screen readers can provide useful information
to their users, we should add an appropriate role
attribute when the underlying element would not have made that
role obvious.
This rule forbids the following:
<div {{action 'foo'}}></div>
Instead, you should add a role
to the element in question so that the A/T is aware that it is interactive:
<div role="button" {{action "foo"}}></div>
Add img-alt-attributes
rule (full documentation).
An <img>
without an alt
attribute is essentially invisible to assistive technology (i.e. screen readers).
In order to ensure that screen readers can provide useful information, we need to ensure that all <img>
elements
have an alt
specified. See WCAG Suggestion H37.
The rule forbids the following:
<img src="rwjblue.png">
Instead, you should write the template as:
<img src="rwjblue.png" alt="picture of Robert Jackson">
Changelog
v0.5.11
nested-interactive
rule to use the new isInteractiveElement
helper function.nested-interactive
configuration. Now uses an object (instead of an array). Example:rules: {
'nested-interactive': {
ignoredTags: ['a', 'button'], // list of tag names to ignore
ignoreTabindex: true, // ignore the tabindex check
ignoreUsemapAttribute: ['img', 'object'], // ignore `usemap` check for specific tag names
additionalInteractiveTags: ['some-custom-tag'], // not sure this is needed, but it seams neat :P
}
}
Changelog
v0.5.10
.template-lintrc.js
file, the foo/bar/baz
module would have only its indentation related issues labeled as warnings:module.exports = {
extends: 'recommended',
pending: [
{ moduleId: 'foo/bar/baz', only: ['block-indentation']}
]
}
All other rules with errors in the foo/bar/baz
template would still be reported as errors.
Changelog
v0.5.9
Changelog
v0.5.8
block-indentation
rule:
{{#if foo}}{{~/if}}
would error.{{else}}
).Changelog
v0.5.7
block-indentation
rule that would throw an error if a block contained a comment.Changelog
v0.5.5
recommended
configuration.pending
in the .template-lintrc.js
configuration file. When a module is listed in the pending
list, it will be checked but any errors detected will be marked as warnings (and will not trigger a failing test when using ember-cli-template-lint). If there are no errors detected when checking a pending file, a new error will be triggered. The goal of this process is to allow large existing projects begin utilizing ember-template-lint
/ ember-cli-template-lint
and slowly fix their template files to comply with the rules here. Feedback welcome on this idea/process...Changelog
v0.5.4
Move rule configuration into rules
property inside .template-lintrc.js
. Configuration in the root is still supported,
but triggers a deprecation warning. Migration should be very straightforward.
Before:
// .template-lintrc.js
module.exports = {
'bare-strings': true
}
After:
// .template-lintrc.js
module.exports = {
rules: {
'bare-strings': true
}
}