Write Better Markup with HTML Inspector

Originally published at: http://www.sitepoint.com/write-better-markup-html-inspector/

We often see quite a bit of discussion of optimization techniques for various areas of front-end development. One area that probably gets more overlooked than it should is HTML.

I’m certainly not a member of the ‘clean, non-presentational markup’ camp. But I do think consistency in markup is needed, especially when working on code that many developers are going to touch.

In this post, I’ll introduce a neat little tool that I’ve revisited recently that I think many development teams would do well to consider using: HTML Inspector by Philip Walton.

What is HTML Inspector?

As Philip explains on the repo’s README, it’s:

a highly-customizable, code quality tool to help you (and your team) write better markup. It aims to find a balance between the uncompromisingly strict W3C validator and having absolutely no rules at all (the unfortunate reality for most of us).

Although I somewhat disagree with Philip’s statement that the W3C validator is “uncompromisingly strict” (doesn’t he remember XHTML?), I certainly agree that many teams of developers likely lack a set of logical in-house standards to keep their markup maintainable and up to date.

After running HTML inspector, you’ll get a series of messages in your browser’s developer tools console, letting you know what issues in your HTML you should consider addressing.

You can see an example of HTML Inspector’s output in the image above, which is taken from a test I ran on one of my older projects, which I knew would likely have some questionable markup.

Install and Run HTML Inspector

If you’re doing testing on your own non-production code, you can simply include the HTML Inspector script in any of your pages, at the bottom, then run it by calling the primary method. Below is a brief description of the install methods, and then I’ll explain an even better method to get it to run on any website, remote or local.

To install and use via the command-line, you can use NPM, which requires PhantomJS:

Continue reading this article on SitePoint

I get the following error "Object doesn’t support property or method ‘keys’ "
Line 1535 of html-inspector.js is where this occurs.
How do I resolve this?

@DoctorG - What browser are you using?

EDIT: Object.keys() is supported pretty much everywhere. See this article on MDN.

Are you using Firefox 3.5 or IE8 or something like that? You can see a similar discussion on this in one of the closed issues on the GitHub repo.

I was running the script inside Homesite using Internet Explorer.
When I run it outside Homesite using Mozilla, it runs OK but does nothing.
I guess I just don’t know how to use this tool.

After you run the script, you also have to call the method: HTMLInspector.inspect() to see the output in the console. You can run that in the console, or else just throw it at the bottom of your HTML, in a script tag, after you include the html-inspector.js script. Hope that helps.

var htmlInsp = document.createElement(‘script’);
htmlInsp.src = ‘//cdnjs.cloudflare.com/ajax/libs/html-inspector/0.8.1/html-inspector.js’;
document.body.appendChild(htmlInsp);
HTMLInspector.inspect();

when i run it directly in console in any browser i got an error
ReferenceError: HTMLInspector is not defined

is there anything need to be configured before or not

Oh I just realized, you have to run the first three lines by themselves, and then call the last line on a separate command. I didn’t realize that at first, as I assumed that everyone would type the commands one line at a time.

I’ll edit the article to reflect this. I should be able to explain more technically why it doesn’t work when you paste the lines all together, but basically, the script that the code is creating isn’t in the DOM until you execute the commands, so you have to execute the last line separately.

@muhamedhashem & @louislazaris
You can use this snippet:

function _loadScript(url, callback) {
    // Adding the script tag to the head as suggested before
    var head = document.getElementsByTagName('head')[0];
    var script = document.createElement('script');
    script.type = 'text/javascript';
    script.src = url;
 
    // Then bind the event to the callback function.
    // There are several events for cross browser compatibility.
    script.onreadystatechange = callback;
    script.onload = callback;
 
    // Fire the loading
    head.appendChild(script);
}
 
var HTMLInspector = {
  url: '//cdnjs.cloudflare.com/ajax/libs/html-inspector/0.8.1/html-inspector.js',
  init: function () {
    HTMLInspector.inspect();
  }
};
 
_loadScript(HTMLInspector.url, HTMLInspector.init);

I use it as a snippet in Chrome. It’s pretty handy.
Snippet: https://gist.github.com/boriskaiser/d3835111498ae0ea09f2
Screenshot: http://i.imgur.com/laD3yxt.png

While I am not against this type of projects (and the good things that they are Open Source and free), I’d rather use the professional-level validator that is compiled and updated with the latest rules to follow the standards and has excellent interface. I use the CSE HTML Validator v.12 (https://www.htmlvalidator.com). And there is nothing better, so far. Yes, it costs few bucks but every cent spent on software pays off.

@boriskaiser

Very nice, thanks!

What would be the best way to use this as part of a grunt build process?

@AMA3_

Which part? The running of the script? Or the correcting of the errors/warnings? I’m not sure if the latter could be automated, because the warnings would really depend on the markup. I guess it’s possible, but it would be a pretty complex grunt task to write in order to do that. I don’t know if that would be practical unless you had a really strict markup structure – but even that would be difficult, in my opinion. But maybe someone else (or the author of the tool) has a better idea.

Running the script. I currently use grunt-html for linting but this sounds like it would do a more thorough job, maybe combined with grunt-html to cover everything.

@AMA3_

Use @boriskaiser’s script as a bookmarklet (see his earlier comment). It works perfectly, just one click and the readout will be in the console. I think that’s as good as anything, and I don’t think a Grunt task is necessary.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.