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.
A digital native focussing on design systems, brand identity and creative coding to help digital products take shape. My approach is organized, systematic and inclusive.
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.
A digital native focussing on design systems, brand identity and creative coding to help digital products take shape. My approach is organized, systematic and inclusive.
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.
HTML pretty much doesn't exists in the source code per se, so linting it would be harder
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.