We use linters such as ESLint and Stylelint all the time but why is linting HTML not a common practice?
I occasionally see people use the W3C Validator but never see specific HTML linters in a build process / pipeline.
Why is that?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (18)
I think by the time linting became a thing, HTML sort of started being treated more like a build target than code itself. I may be offbase, but I feel like templating languages like erb, ejs, etc. plus pseudo-html now with React.
I just feel like cleanliness of HTML is not really "a thing".
This is me riffing, not really sure.
Isn't that a shame? Or shouldn't we care more about this? Writing semantic and clean HTML is really important for screen readers.
Yeah I agree. At least about the semantic part. It doesn't necessarily have to be human readable if it's more of a build target, but yeah it should definitely be semantic. And in this case, it seems like it should especially be linted. It's no longer about the developer experience here, it's the user experience.
In this way, linters are not like spell check because they're not going to necessarily affect the way the end user "reads" things, but for HTML it would be like a true spell check.
I'm sold.
I guess because we don't write much of it, it is a loose markup and browsers are very forgiven. I still close my single elements
<br />for example, XML and XHTML left some scars on my brain :), but the new generation of developers write very looose HTML and is working.And also we have bigger fish to fry, JS code quality is still lacking in most projects.
Agreed, a browser is very forgiving in the case of displaying the page. Screen readers (and SEO / SEA) are not.
Not quite sure if JS code quality is more important then marking up a webpage if we talk about progressive enhancement.
I may express myself wrong, the HTML specs are "forgiven" not only the browsers, so all parser should be, including screen readers and SEO bots. Example some tags ends can be omitted, and some even start tags.
I didn't knew we talked about progressive enhancement only, I was just replying to the tile, HTML linters maybe will be used after we start using JS and CSS linters, which has more complexity and can cause bigger problems.
Either way most of the HTML nowdays are inside N template systems, concatenated strings, or generated by "shadow DOMs", so HTML pretty much doesn't exists in the source code per se, so linting it would be harder, and done on the end product.
Ah, I get your point! I coined up progressive enhancement since, in my opinion, we focus more on CSS and JS because people tend to find them harder languages. They are most of the time regarded as more complex which I don't agree with.
It will impose a challenge but we figured it out with preprocessors and other compiled languages so I guess we also can when we're using templating languages.
Just a wild guess but: code is done by developers, and most developers like good code, hence the use of linters.
HTML on the other hand, is arguably not "code", it's markup. And it's also written by non developers on many occasions, and those "non developers" might not want to lint it (if they even know what a linter is).
Indeed, HTML is not a programming language but it's still one of the three pillars for making a webpage. But since we strive for the best
codequality, why shouldn't we do the same formarkup?Quality standards should indeed be the same for code and for markup (and also for anything we type, actually).
๐
We're friends here, right?
Truth. I had no idea what linting was before this summer. I found out what it was in the middle of a study jam for my Mobile Web Specialist Nanodegree.
I haven't fully grasped how to put it into practice yet. The concept seems great for sites on a larger scale. So far, I haven't worked a project big enough that would have to benefit from figuring out and installing a linter. I do email development at work (single, static HTML file) and we've mostly moved to a WYSIWYG solution, so no linting needs there.
That said, a linter would be helpful for the console errors I'm getting from the javascript in my ND project files. I've spent way too much time debugging.
How would this work for HTML though? The only rule for HTML is that tags need to be closed (except for some that are void). All IDE's have HTML formatters I think.
That's purely Syntax and indeed most formatters will give you warnings about those. But what about semantics? Right tags for the right content or missing
altattributes for example?I see what you mean. That's an interesting way to help you improve the code quality.
I was working on an open-source tool called TesterBot and the idea was to point out such issues sort of in a post-build test automation. However, I stopped because of LightHouse. Although, I'm contemplating restarting the project when I get some time and sooner if someone else finds it interesting. :o
I was also planning on implementing things listed in the FrontEndChecklist
Automatic Front-End Testing
testerbot
Automatic Front-End Testing
Purpose
During development, there isn't enough time to write tests, so our only option is manual testing. We don't need a reminder of how inefficient, time-consuming, error-prone and boring that can get. When we get around to writing test-automations, we spend a lot of time writing tests from scratch. However, most of the test-cases for testing web-applications can be automated and reused.
We created Testerbot to automatically test web-applications during the development process via Puppeteer which talks to Headless Google Chrome.
The basic framework is ready and we have implemented a few test-cases, but we need help in adding more reusable test-cases.
Note: I started this project several months ago and built a SaaS product, but realized that an open-source test automation package will help catch issues quickly during development. I recently stumbled upon frontendchecklist.io/ and created github issues to automate as many of thoseโฆ
For what it's worth eslint-vue checks HTML (Vue) attributes and their ordering, and with prettier configured you also get auto formatting. But, it doesn't exactly check HTML, it just checks that the attributes are correct in the context of Vue, the rest is a byproduct.
I was about to slam down and comment that this exactly what prettier does, only to realize that it doesn't support HTML. Pretty weird.
I think it's because HTMLHint isn't as good as it could be. Don't get me wrong, it's helpful, but there are all kinds of things it can't handle right, like inline SVG.