Does HTML need a lint tool?

[itpastorn]

Hi all!

Most coding languages have a lint tool or another way of enforcing coding conventions. HTML does not. In fact, the one lingering reason to use XHTML syntax seem to be that it enforces a strict syntax, that helps you to avoid errors.

Validation is not enough. Consider the following criteria, which is a set of rules that makes sense to me:

1. Attributes that may take more than one word as a value must be quoted.
2. Attributes that are boolean should be shortened.
3. Attributes that take exactly one word or an integer as a value may be quoted.
4. Tags that have optional closing tags must be manually closed.
5. Void elements must not be manually closed.

Those requirements would IMHO strike a balance between readability, robustness, while allowing for the removal of redundant characters (=less page weight).

My question: Would you be interested in an HTML lint tool that could check your code for things like these?

If so, what else or what other conventions would you like to be able to enforce?

[AutisticCuckoo]

Since some of the rules you list are rather arbitrary and subjective, I think such a tool would need to be able to read a configuration of some sort from which it would know which 'rules' to apply. (And those that aren't arbitrary and subjective are already covered by validation.)

It sounds more like a tool for enforcing a company/project style guide than a true lint app. And doesn't HTMLTidy already let you do many of those things?

To answer your question: no, I wouldn't be very interested in such a tool. I handcode my markup and I do it very consistently. Validation is sufficient for my needs, to point out the occasional mistake.

[Stomme poes]

Most coding languages have a lint tool or another way of enforcing coding conventions. HTML does not. In fact, the one lingering reason to use XHTML syntax seem to be that it enforces a strict syntax, that helps you to avoid errors.

Actually, and unfortunately, XHTML doesn't enforce anything. If you write cruddy XHTML, instead of sitting down and holding its breath until it passes out, it goes ahead and tries to hide your errors : ( Nothing enforces coding conventions but the coder him/her self.

I've started saying, it's not XHTML that's strict, it's not the validator who's strict, it's the AUTHOR who's strict.

A lint program is best for catching typos and things. The validator does that, most of the time.

[itpastorn]

OK, 2 guys dont want or need a lint tool for HTML, partly based on misunderstanding my thread startener. It was not intended to be a complete suggestion, since I wanted this discussion to be open.

Nothing enforces coding conventions but the coder him/her self

That was my sole intent to discuss. In teaching and co-operation environments it makes sense to have a tool that actually can check such things. Today one must enforce conventions manually. Why not have a tool to assist you?

As for conventions being arbitrary?

Let's look at a rule in JSlint: One should have a space between arguments in function calls. Is that "arbitrary"? "Subjective"? Yes, but somebody (the renowned D. Crockford) has found that it makes sense, even though omitting that space does not invalidate script execution.

In a similar fashion I have found that demanding that my students quote attribute values always reduces errors and lets me spend time helping them fix real problems. Today I order them to use XHTML syntax. (Yes, sent as text/html.) Since they can use tools that catches unquoted attributes.

In order not to make this discussion focus on small parts of a coding convention I did not post any links. I have however given this some thought, so here they come!

http://itpastorn.blogspot.com/2009/0...lse-xhtml.html

And this thread I started at WHAT-WG:
http://lists.whatwg.org/htdig.cgi/wh...ly/021317.html

You do not have to read the whole first post. But there are replies that have influenced my starting this thread here.

[logic_earth]

Most coding languages have a lint too...HTML does not...

That might because HTML is not a coding/programming language but rather a markup language.

1. Attributes that may take more than one word as a value must be quoted.

This is already solved by [strict] validation, attributes are always be quoted.

2. Attributes that are boolean should be shortened.

I assume you mean attributes like "disable" on inputs. HTML doesn't have real data types (bool, integers), but you can use [strict] validation to enforce "disable="whatever""

3. Attributes that take exactly one word or an integer as a value may be quoted.

Except...attributes values should always be enclosed in quotes...

4. Tags that have optional closing tags must be manually closed.
5. Void elements must not be manually closed.

Also solved by [strict] validation.


As far as I can see the only reason for an HTML lint s for formatting but not for enforcing the syntax of the HTML, that is up to validation.

[AutisticCuckoo]

Except...attributes values should always be enclosed in quotes...

Sez you!
HTML allows the quotes to be omitted if the attribute value only consists of letters, digits and certain other characters. I agree that it's good practice to always use quotes, but you can write valid HTML 4.01 Strict without quoting every attribute.

Also solved by [strict] validation.

No. Omitting an optional end tag is perfectly valid and the HTML validator won't complain about it. And <p/> is, technically, not necessarily invalid HTML; it just doesn't mean <p></p> as in XML.

[itpastorn]

Logic earth, you are discussing my examples of what one might wish to enforce. Wishing to enforce different rules does not affect the need for a lint tool per se.

The thread at the WHAT WG mailing list had quite a lot of replies from people who did not wish to enforce quotes for attributes that can only take integer or single word values, like maxlength or type. I chose their example. Saying it makes sense to leave quotes as optional for these, since omitting them never can break their functionality. I personally will use quotes, since it increases readability, IMO, except for boolean attributes.

Tommy has already explained that the validator is not checking any of these things (not an opinion, a fact), and that leaves my argument for linting or "code convention" checking (a longer, but probably more accurate name) unrefuted.

Just one nit - you probably know this - but for all my students who might see this thread ;-)

disable="whatever"

That is not valid at all. The disabled attribute (notice the d at the end) can be written in exactly four ways (ignoring optional white-space):

disabled="disabled"
disabled=disabled
disabled=""
disabled

Since every other way of writing that attribute is invalid, it will be caught by a validation tool.

Returning to my main point:

A code convention checker will help me to enforce one of these 4, should I wish to do so.

It also might help enforce things like line length, indenting, keeping tags and attributes lower case, even though one does not use XHTML syntax, etc. I was things like this that I had expected people to think of.

And, Tommy, yes, configuration options must exist, just like they do for HTML Tidy or JSLint. (And Tidy won't solve all my use cases. I wish to check things like this, not convert like Tidy does.)

[zcorpan]

I think it would be useful, and I also think it would make sense to add it to validator.nu in the form of a checkbox option "Show Coding Style Report" that reports the actual coding styles used, similar to the Image Report feature.

This wouldn't clutter the UI with a bazillion options and wouldn't give one coding style higher status than others, while still allowing people to enforce a particular coding convention if they want to.

[zcorpan]

http://bugzilla.validator.nu/show_bug.cgi?id=630
http://bugzilla.validator.nu/show_bug.cgi?id=628

[felgall]

An option to validate that HTML complies with all the additional rules that were added to XHTML that can be applied to valid HTML would be useful since all those things which are optional in HTML and mandatory in XHTML would make the HTML far easier to maintain.

That would also remove the need for a lot of people who code their pages as XHTML and then serve them as HTML simply in order to use the XHTML validator.

[AlexDawson]

I am with Tommy on this, I really don't see a need for such a tool, while malformed code seems to be still rampent the kinds of people who would bother to install and use such a tool would probably not be those who are even aware their code is rampent with errors. HTMLTidy is a tool which does a good job at sweeping up some of the mistakes but perhaps I am the only one cynical at the prospect of a tool intended to fix markup issues when the majority of those issues aren't made by hand coders but are made up by those using WYSIWYG editors (who don't understand code and use the visual window).

[itpastorn]

@AlexDawson:

Two use cases to consider:

1. Consistent coding standards in organizations involving multiple developers.

2. Academia.

[felgall]

HTMLTidy is a tool which does a good job at sweeping up some of the mistakes

The only problem with HTML Tidy is that it can break some JavaScript internal in the page (a good reason for only using external JavaScript) and can also break the value assigned inside a <textarea> where the formatting can make a big difference to the content.

[Stomme poes]

That was my sole intent to discuss. In teaching and co-operation environments it makes sense to have a tool that actually can check such things. Today one must enforce conventions manually. Why not have a tool to assist you?

Well, the only way I can think to truly "enforce" anything (as I can also write Javascript and choose not to run it through JSLint and still I get no jack-booted nazi thugs entering my room in the night-time to drag me off to JS purgatory) is to make the interpreter of the language in question (so in this case, the browsers) refuse to work when there are bugs or if the coding isn't even up to a certain style. Truly, the only way to force someone to do something a certain way is to make any other way break.

Which nobody but me and a few other Nazis would do : ) If I ever write a language, it will have strict rules, and breaking them would definitely make anything unintelligable. It would not follow Postel's law, and would ultimately also not be flexible (you have more flexibility when multiple versions of a language are mutually intelligable when they are just "close enough"... there was a talk about this at YAPC and the example given was a Swede talking to a Norwegian in Swedish, while the Norwegian talked back in Norwegian... and Matt called this "Scandawegian" which I love so much I'll likely use it myself).

The other option, for within Company X or School X, is an internal guideline, one equipped with said jack-booted thugs, made up of rules everyone agrees to upon penalty of death (and signed with their own blood of course).

1. Consistent coding standards in organizations involving multiple developers.

Many use a wiki of some sort. This is valuable for any language, so everyone's not coding in different, possibly mutually unreadable but still valid and working, ways.

I think the idea is cool, but for me as a coder, my Lint already exists: the validator, and my own native nazi-ness.

The disabled attribute (notice the d at the end) can be written in exactly four ways (ignoring optional white-space):

I get told off if I do disabled=disabled, or any of the other versions, because I'm told the value should be in quotes.
The only way I am allowed to write, if I'm using the validator, is disabled="disabled". Period. However, just like any Lint program, I am free to ignore that message if I want just

disabled

to work. So, just as a Lint program can't force me to do anything correctly (only suggest things, if I chose to care enough to run my stuff through it), neither can a validator send the storm troopers to my house. How does a Lint program force anyone to do anything? I may be misunderstanding this, but this is why I say the author is the strict one. The author is the one who chooses to run their JS through JSLint, and it enforces nothing (because it cannot force anyone to write lint-approved code, can it?). I enforce the rules of my code.

[Arlen]

I find myself in near-complete agreement with Alex on this (someone nearby, please rush the defibrillator unit over to Alex's house immediately, he may have just dropped into a serious state of shock).

I can see a use for such a tool in academic environs, when dealing with novice coders, and can see perhaps a use for it in large shops, but even large shops only have a few front-end developers, for the most part. Plus, large shops are more likely to deal in large code bases where much of the front-end work is "canned", so therefore doesn't vary from project to project, negating most of the benefit of it.

The next reason against the use of such a tool is the trivial amount (relatively speaking) of HTML written in most shops today (compared to programming languages). Web sites of any size aren't made up of static pages, but a far smaller number of template files through with the db content is poured. Some of that code is written by hand, but much of it may also be written by other tools, lowering both the need and ability to edit it.

Since these systems are made up of chunks, each of these chunks can be individually tested when they are created, by the usual suite of automated testing tools, for good output. No need for a lint when things get checked in the unit tests.

So once again we come down to using a tool to look at a handful of files for same basic "house rules". Where there are huge amounts of development code, there isn't of HTML, so the economies of scale don't factor in.

Were such a tool provided to me absolutely free, I just might pick it up out of curiosity, but I would highly doubt it would find its way into my toolbox. It certainly wouldn't if there were a price tag attached; there's no viable ROI I can see.

[AlexDawson]

I find myself in near-complete agreement with Alex on this (someone nearby, please rush the defibrillator unit over to Alex's house immediately, he may have just dropped into a serious state of shock).

When I read that I almost choked on my coffee