The case and rules for formatting HTML in 2015

examples

<!-- OLD -->

<span class="my-class" custom-attribute="an-attribute" id="thing1" title="my title" inline-js-exec="something===another">Some Content</span>

<!-- NEW -->

<span 
  id="thing1"                           <!-- Note that id is first (if it exists) -->
  class="my-class"                      <!-- Note that class is second -->
  title="my title                       <!-- Other HTML standard attributes next -->
  custom-attribute="an-attribute"       <!-- Custom attributes -->
  inline-js-exec="something===another"  <!-- Custom attributes with inline JS -->
  >                                     <!-- training > rids of of issues with commits effecting lines because the caret moves -->
    The temp outside is                 <!-- Content gets tabbed in and goes on its own line -->
    {{is_celcius ? tempC() : tempF() }} <!-- Interprated content should ideally go on its own line -->
    degrees
    {{is_celcius ? "C" : "F" }}
</span>

Intro

HTML has grown up and so should the way we format it. Despite early objections, nearly every developer and team which has adopted this formatting realizes it is supremely better at:

1.) Collaboration and Version Control
2.) Reads Easier and Faster
3.) Separation of Concerns

Under the current standards of html we see a lot of this:

<span class="my-class" custom-attribute="an-attribute" id="thing1" inline-js-exec="something===another">Some Content</span>

As an experienced web dev this is easy enough to read, but we have to ask ourselves: 

'Why is it ok to slop content, markup, and expressions into a single line?'. 

If you've ever worked with a big web team you might also find yourself asking: 

'Why am I wasting my time on all these merge conflicts?'

Two, three, or four different engineers should be able to work on the same file and it is a common occurrence. In addition the persons reviewing and merging code shouldn't need to be trying to pick through lines and figuring out who changed what.

XML, MXML, and VB, and nearly every other markup language has established standards for these exact same reasons. 

Below is my proposal of how HTML should be formatted from 2015 and beyond. 

Q&A and Exceptions

Exceptions

On some teams we have incorporated exceptions of when we can do it the old way. Here are a few examples

1.) When there are no attributes or content do it 
2.) When there are no attributes and the content fits on one line
3.) When there are only 2 or less html standard attributes and no content

Arguments:

Q : "What about all this whitespace? It is going to ruin my content"
A : "HTML whitespace rules are simple and well defined. This formatting has no effect on the content being displayed"

Q : "The files are too big and a lot of wasted characters and newlines are being sent to the browser"
A : "If you have these sort of concerns you should be gzipping or post-processing you html so no formatting will matter matters once it leaves your web server."

Q : "Its so burdensome to read so many lines"
A : "Once you get used to it you will realize the real burden was trying to read it the old way. In this format you can expect to find properties in certain places and the content is clearly separated."

Q : "Seriously though, its just a span."
A : "This is a complex component which is a combination of interactions. Some happening server, others client. Its dependent on external (js and css) resources too. Consider if javascript functions were all one-liners?"

Q : "Why does it matter if interpreted content goes on its own line"
A : "This is probably the least important part of the proposal, but it is another way to separate concerns."