By default, any class prefixed with js-, language-, or supports- is whitelisted. The "unused-classes" rule compares all the class selectors in the CSS to the classes in the HTML and reports any that aren't being used.Ĭlasses that are in the HTML as JavaScript hooks can be ignored via a whitelist. Unused Classes: Sometimes you'll remove a CSS rule from your stylesheet but forget to remove the class from the HTML. If a script must appear somewhere other than the end of the document, it can be whitelisted.
Because JavaScript is a blocking resource, adding elements anywhere other than the end of the document may delay the loading of the page. Script Placement: Warn if elements appear anywhere other than right before the closing tag. Inline event handlers are hard to manage, hard to debug, and completely non-reusable. Inline Event Handlers: Warn if inline event handlers, like onclick="return false" are found in the document. (Note that everything in this list is subjective and optional.) The following rules check for these types of things. Some markup may be perfectly valid but uses practices that are commonly considered to be poor or outdated. Unique Elements: Warn if elements that should be unique (like and ) appear more than once in the document.
If your project uses custom attributes (like ng-* in AngularJS), these can be whitelisted.ĭuplicate IDs: Warn if non-unique IDs are found on the same page. Validate Attributes: Like validating elements, this rule will let you know if you're using attributes that don't belong on a particular element or perhaps don't belong on any element. An example of this is a block element like appearing as the child of an inline element like. Validate Element Location: Make sure that elements don't appear as children of parents they're not allowed to descend from. Any element you don't want to be warned about can be whitelisted. This will catch simple things like misspelled tags ( instead of ), and it will inform you of deprecated tags (like, , and more recently ). Validate Elements: Inspects each element in the DOM and reports any elements that are invalid or obsolete. (Expect this list to get more comprehensive in the future.) Here are the validation rules that ship with HTML Inspector. That being said, there is still a lot that it can do (and does) to validate your markup. Because HTML Inspector runs after the browser has parsed your HTML, any mistakes the browser has forgiven will not be seen by HTML Inspector.Īs a result HTML Inspector should not be seen as a replacement for validation. This makes it a lot more powerful, but there are some drawbacks as well. Validators parse static markup, while HTML Inspector runs on a live DOM. HTML Inspector is different than a markup validator. The following is a more in-depth explanation of each rule: Validation Here are the default configuration values:
The function is passed an array of errors that were reported by individual rules. onComplete: (Function) the callback to be invoked when the inspection is finished.excludeSubTrees: (selector | element | Array) the descendants of any DOM element that matches the selector, element, or list of selectors/elements will be excluded from traversal.excludeElements: (selector | element | Array) any DOM element that matches the selector, element, or list of selectors/elements will be excluded from traversal (note: its descendants will still be traversed).If useRules and excludeRules are both set, the excluded rules are removed from the list of rules to use. excludeRules: (Array) a list of rule names not to run when inspecting.Defaults to running all rules not excluded via excludeRules useRules: (Array) a list of rule names to run when inspecting.domRoot: (selector | element) the DOM element to start traversing from.The inspect method takes a config object to allow you to change any of this behavior. Configuring HTML Inspectorīy default, HTML Inspector runs all added rules, starts traversing from the element, and logs errors to the console when complete, but all of this can be customized. Make sure you call inspect after any other DOM-altering scripts have finished running or those alterations won't get inspected. After the script runs, any errors will be reported to the console (unless you change this behavior).