Versions: SQ 8.3, scanner 4.3.0, css plugin 1.2.0
The subject rule flags CSS selectors that specify a “non-existent” tag name. My problem is that the definition of “existent” is very difficult to nail down once you start writing your own web components.
I like the idea of having a rule that catches when I misspell one of the core HTML tag names, but it all falls apart when your project uses web components, or Angular, or Vue, or any other framework that works in a similar way. I don’t currently limit my components to a single prefixed namespace, but even if I did, the rule would be of limited value since it would check for typos in predefined tag names, but not in the names of components defined in the project.
The current implementation defaults to exclude some popular prefixes (md-, mat-, fa-) but it can’t possibly be a good idea to ship a rule whose functionality depends on what libraries are popular at the time. It requires that the rule be re-configured to suit any project that uses custom components, and forces those components to be named with a prefix scheme that can be whitelisted via regex. (This is arguably a good practice, but the web component naming guidelines I found only say that at least one dash is required, and explicitly state that prefixing is not necessary for private-use components.)
I originally titled this post “The impact of web components on S4670” but while I was researching and writing it I had a realization: this rule will never have a true negative – that is, it will never¹ examine a selector and find that it passes the rule – if there’s a dash in the tag name, because no “existing” tag names include a dash (except per footnote). Valid web components must have a dash in the name per the custom element spec. So, if a user typed a dash in their CSS selector tag name, they must be referring to a custom element. As far as I can tell, it’s impossible for the CSS plugin to verify the existence of custom elements by name. Therefore, flagging tags with a dash in the name is useless.
The rule should ignore tags with dashes in the name and assume that they refer to a web component / custom element. This would also allow the rule to get rid of the ignoredTypes parameter entirely, since all the current default cases would be covered².
¹ There’s a short list of exceptions in this page from webcomponents.org from SVG and MathML, but no dashes in HTML. I’d argue that the value of catching “missng-glyph” as a CSS selector is minimal compared to the reduction in false positives that we’d see with this proposal.
² You could argue that users have already customized this property for their own projects, but if they configured it to any value that doesn’t end with a dash, their components are violating the custom components spec, which is an actual code-quality issue that should be addressed.