Linting HTML using CSS | Hacker News Reader

Linting HTML using CSS

bitsofco.de

326 pointsbasename49 comments

So... this: https://github.com/imbrianj/debugCSS ?

I toyed with something similar a few years ago, although didn't pursue it to this depth. One issue, though: border is definitely not the right way to highlight elements in this manner since it affects layout. I'd go with outline instead.

Does it affect layout if you use box-sizing: border-box;?

Soundly checking HTML, including all kinds of customization and more is possible using SGML.

[1]: http://sgmljs.net/blog/blog1701.html

Your comment sent me down a multi-hour rabbit hole.. thank you. I ended up reading a fair bit about Marcus Reichardt's initiative toward a SGML DTD for HTML5.1. However, i was unable to find a place where a tool or said DTD was available for download. Do you happen to have a link?

For now the full DTD grammar can be downloaded from the "Restrictive DTD" tab link of the full paper eg. [1] via copy/paste. I intend to be make it accessible on a permanent URL once I get more feedback/review comments. It can be processed using the venerable OpenSP/OpenJade package (install it with "sudo apt-get install opensp" on Debian/Ubuntu or "sudo port install opensp" on Mac/MacPorts; don't know the MacBrew equivalent, though). I'm using my own sgmljs SGML system (public release upcoming/pending).

[1]: http://sgmljs.net/docs/w3c-html51-dtd.html

You could probably also do something similar to the article, providing your document is XML-valid, using XSLT. This would keep the advantage that you just load your document in a browser (having added a temporary stylesheet link either manually or dynamically) but would support more powerful validation. It could be made into a browser extension so you're just a one-click away from validation with in-page feedback.

Of course, you can also validate XHTML using the provided DTDs if you take out the SGML-specific bits, using a (DTD-)validating XML parser (or indeed use XSLT as you say). But SGML has tag omission/inference, empty elements/HTML "void" elements, attribute short forms, unquoted attributes, Wiki syntaxes/markdown, and other features desired or even required for mere parsing mainstream HTML. As to using XHTML, I'm not sure it has a bright future. Last I've worked with it was like ten years ago (xsl-stylesheet processing instruction etc. on IE6; newer browsers don't seem to support it anymore).

FYI: SGML is way more powerful than XML, and its grammar formalism is identical to that of XML because XML was designed as a simplified subset of SGML. Though Relax NG, and also XML Schema, can theoretically express richer grammars than SGML, they can't be used for HTML due to lack of tag inference and other short syntax features, and the features that Relax NG has over SGML benefit data-oriented rather than document-oriented use cases (eg. the use cases that JSON and other serialization formats are arguably better suited for than markup in the first place IMO).

sgmljs.net can run (also) in the browser, so can also validate HTML5 in the browser.

Disclaimer: my project

I've had success with xhtml and xslt processing on the server-side. The fact that it's xhtml is incidental; that it's xml-valid means I can use a wealth of established tools to modify the content, and easily write my own. I don't mind too much about xml support in the browser, although I've found xslt to still be supported in chrome - e.g. for rendering RSS feeds as HTML.

This is fantastic! (Forgive me, but s/detailled/detailed/ in the link at the bottom.)

Thanks very much. Keep your findings coming, I'll be happy for any feedback.

This is a good choice of selectors, but I wonder what styles one should apply to <meta>, <script>, or <link> tags that will get them to actually display anything. Some fiddling in Firefox didn't reveal the solution.

display:block will show them. Those elelemnts are not impossibly visible, they are just display:none by default

If they are inside the <head> you have to display: block that first, try something like:

    head, meta, style, script, link { display: block; }

Is there a reason the * selector is needed on the first example or am I missing something? I believe [style] { } would get the same result.

The '*' there has no effect whatsoever. It doesn't even change the specificity.

  a:not([href])  
  a[href="#"],  
  a[href=""],  
  a[href*="javascript:void(0)"] { … }

Wait, what should I use instead then?

The button element should be used for interaction that is not navigation to a different url.

What about anchors using name?

They've been deemed obsolete with HTML5 - you should use the id attribute on the element the <a> would be naming.

I was thinking the same when I saw that... Not sure if it's viable, but maybe buttons?

Always supply an href so JavaScript-less viewers can still activate the link. Attach events via JavaScript rather than HTML attributes.

Reminds me how some video games would use really garish default textures, so that the errors in texturing stand out.

I believe Thief 1 and 2 have done this, but I may be wrong.

It's also similar to what Microsoft does (did?) with Windows during development[0] - text that hasn't been translated yet is shown with a whole bunch of meaningless diacritical marks and replacement characters so it stands out.

[0]: https://en.wikipedia.org/wiki/Pseudolocalization#Pseudolocal...

The Source Engine (of Half Life and Counter Strike fame) uses a checkered black and bright pink texture for missing textures. It really is garish, as I discovered when playing Garry's Mod back in the day.

Doom2 has the classic "AASHITTY"

John Romero learned this in his early days at ID Software: it's crucial that you can still boot the game even when things are missing, but make them very apparent.

Source: somewhere in this video https://www.youtube.com/watch?v=E2MIpi8pIvY

Interesting idea though I think the best choice is a VLI linting tool configured to check these and editor integration.

You could also use JS and log the info to console. Last thing you want to do is this making its way into production and it probably will: sods law.

I just think the most efficient approach is to log violations to a console with exact line numbers.

Hi guys i already made a github repo as a follow up from this article you can check it here: https://github.com/lendk/Lint-HTML-with-SCSS-CSS

Very cool trick. If interested, there is a node cli module which tests against W3.

     npm install html-validator-cli -g
     cd "$HOME"/Sites/mysite
     html-validator --verbose --file=index.html

Inline styles are what keeps my React code maintainable :-)

Why isn't there an HTML linter in the same way there is ESLint for JavaScript?

There is tidy. I was going to say "but it's not kept up with standards", but find whilst researching this comment that it has been extended to HTML5.

https://www.w3.org/People/Raggett/tidy/

Search shows a few other options as well: https://duckduckgo.com/?q=html+linter&t=ftas&ia=web

Unless I'm misreading your question.

It would be nice if this was all bundled in some easy to include package

broken XML leading to browsers applying inconsistent closing tags is a much bigger issue than missing attributes or inline CSS

this kind of linting can't spot broken document structure

Sure, but lets say you have well-formed HTML tags. At that point you're looking for things semantically "weird" as opposed to structurally wrong. This helps there.

HTML isn't XML. HTML is older.

The rules for this are specified in the html5 spec. Also, some tags are not allowed to be closed, and others are only optionally closed. (like li and p)

If you have to apply CSS to find elements with inline styles, I think you have a more serious problem.

And telling everyone that every one of their images must have an alt tag is draconian. Sometimes an image is purely decorative. Sometimes an image doesn't convey any more than the paragraph beside it. Often an alt tag is written in a perfunctory way, or even when it isn't, it doesn't truly make things better for the blind person. I think they should be at the writer's discretion.

I like using these to diagnose what kind of lemon a client just brought for maintenance, but they can be pretty nice to ensure you got your final product right too.

This makes some sense, but it occurs to me that a blind person has no way to distinguish between an image that has no alt tag because it would be meaningless, and an important image that the author simply didn't think to write an alt tag for.

alt="(Decoration)" would clear it right up and only takes a few seconds.

alt="" means decoration - screenreaders will ignore it.

According to TFA, an image with no alt tag will cause some screenreaders to read the src, so a purely decorative image should instead have a null alt tag.

Yep. (And with the fingerprinting / cache-busting most of us do for our assets these days, the result is painful. Listen: https://www.dropbox.com/s/blln31qfzviwf7k/say-0ffe34b4e04c2b...)

Your comment is actively harmful. You are spouting off a strong opinion that hasn't benefitted from any actual knowledge of the topic — or from actually reading the article — or from thinking about it for a more than a second.

As the article correctly states, an alt attribute should always be present; explicitly empty values signal that no alt content is needed for a screen reader.

An image without the alt attribute is not even valid HTML. Try it yourself: https://validator.w3.org/nu/#textarea

I think it's smart that alt is required. Many of us would otherwise blithely continue on without considering accessibility. (Sadly, most of us still do, and we build tools and abstractions that "automatically" set the alt to something, be it an empty string or the file name… defeating the purpose of inviting the author to explicitly create an alt content.)

Back to your comment - if you are of the habit of shitting on ideas just to provoke a defense of them in order to ultimately learn something, I suggest you find a more constructive approach to learning… you could have googled it for 15 seconds and could have instead written, “I thought making a rule of always including alt was dumb, but I googled it and discovered that it's required by the HTML standard because x, y, and z”

   > You are spouting off a strong opinion that hasn't benefitted
   > from any actual knowledge of the topic
   > or from thinking about it for a more than a second.

I made my first website in the late '90s and have been doing web apps for a living for over a decade. I have thought about it quite a bit over the years, and I have been on both sides of the issue.

   > just to provoke a defense

I was not looking for a defense. I was trying to help others not feel guilty for not doing something that I think seldom makes a real difference. I'm thinking of most of the articles I have read, and I'm thinking of the difference to a screen reader in either case: (1) stopping to read some alt text or (2) simply silently skipping over it and just reading the article. In many cases I think it's best not to break the flow or waste the person's time.

   > An image without the alt attribute is not even valid HTML.

The spec says it is for a few cases (https://html.spec.whatwg.org/multipage/embedded-content.html...). But yes, for the case I'm thinking of it insists we explicitly put alt="". I think this is tedious and overstepping its bounds. If a writer doesn't want to put alt text for one of his images, he shouldn't have to. He chose to write an article instead of doing nothing.

And I'm not really talking about being lazy. I'm talking about not wasting the reader's time. If you tell everyone it's better to put an alt tag than nothing at all, then you're going to get a lot of poorly written and annoyingly redundant alt text. If someone writes a text-based article, then it is handicap-accessible, with or without alt tags. What might be less accessible would be an article typeset with images (which is rare nowadays anyways) --- but even then, computers are so good now at deciphering images that even that might not be much of a problem either.

Just say you were wrong. This is embarrassing.

Why do you think I was wrong?

I think you overreacted.

There is no "shitting on idea" in the parent comment (if you disagree, could you highlight what you mean by that?).

Also, "actively harmful"? What do you mean? He only nuanced the article message.

Reply on news.ycombinator.com