4 Quick HTML Rules You Should Know

4 Quick HTML Rules You Should Know

When I heard about arguments erupting at the work place over proper line spacing(double space or tab?), I though it was hyperbole. Like, really? I mean, I get fighting over the superiority of one language over another, but line spacing?

Then I joined a team to build an app and a problem arose: we coded HTML differently from one another. Style guides I’d read in the past stressed the use of double space, but, apparently, another member of the team liked using tabs because, “Sublime allows you to minimize elements based on tab spacing,’ he claimed.

We ended up agreeing on tabs because I’m a team player.

Looking back on it, I should have referenced the style guides that insist on double spacing. Anyway, that’s why I’m going to go through a rundown of the major rules for HTML. I’m also going to go over CSS rules in a future article because HTML and CSS go together like [insert horrible parable(bread and jam’s my choice, if you wanted to know)].

Jokes aside, agreeing on a universal set of rules is crucial for scaling and maintaining large apps. Of course, a pre-processor like Pug is a good mediator. That’s if you’re using Node.js for your back end, of course. You also have Slim and HAML for Ruby.


Pug Life

Really, don’t read the rest of this article. Just use Pug.

But if you insist on writing markup, here are four guidelines.

1) Filenames

Filenames must be lower case.

Good: pugs.html
Bad: Pugs.html

If you need your filenames to be longer than one word, they should be separated by hyphens.

pugs-are-in-the-kitchen.html

2 )Document

Most know that an HTML document must start with !DOCTYPE html. The head and body tags are also standard, though, as of HTML5, your code will work if you omit the and tags. But omit them at your peril.

You still have to specify a language:
html lang=“en”
You have to define a character encoding:
meta charset=“utf-8”
You actually have to include a viewport:
meta name=”viewport” content=”width=device-width, user-scalable=no”

3) Comments

Interestingly enough, there are do’s and dont’s for comments in HTML.

A single line comment should have spaces between the delimiters.

!-- TODO: Make pug carousel --

Multiple line comments must start on their own line. No indentations this time.

!--
One pug
Two pugs
Three
--

Closing tag comments should include the id or class of the element

!-- #pug-carousel --

Important: I think it’s safe to say that comments shouldn’t contain sensitive information, like an API key.

4) Formatting

Okay, up till this point, everyone pretty much agrees with the do’s and dont’s of setting up the document.

Indentation seems to be the beginning of the crossroad.

I’ve seen one guide that emphatically stated that you MUST use tab for child elements. But, I’m going to side with Google and W3Schools and say that double spacing child elements is far more consistent. And, personally, double-spaced elements are more readable.

According to Google’s technical writer,

“ Different text editors interpret tabs differently, and some Markdown features expect spaces and not tabs.”

So, don’t shoot the messenger. All that matters is that you get your team to agree to one style and have that become the end all, be all.

Line breaks should be employed after 80 characters of code.

Trailing white-space at the end of lines should be removed. If you want to know why trailing whitespace is a big deal, read this.

Conclusion

Style guides help to maintain a level of consistency, not only between teams, but across industries. From an outsider’s perspective, they may seem like the outcome of fussy coders; but, in reality, we all need to be governed by rules. We’re surrounded by them for a reason. On a macro level, we have the laws of physics that ground us on this planet. And, on a micro level, we have style guides. What can I say?