When we work with a browser, everything is an object, that is an associative array of key-value pairs. CSS declaration blocks are an example of an associative array.
font-family: Georgia, Times, serif;
The colon separates the property name from the value. The selector is the identifier, and curly braces enclose the declarations, hence, declaration block.
Now the DOM nodes for all of the paragraphs in the document have these attributes, in addition to any given the element in the HTML.
So each element is an object, or rather collection since that DOM node will consist of a tree of all the child elements, along with all their attributes and properties. The DOM is a very crowded place.
Element attributes are written as the syntax allows, namely,
As long as they are composed this way, repeatedly, the order is of no importance.
For consistency, and when working on a team, everyone should agree upon an order, though, since it helps when scanning markup and debugging if the order is consistent. That is a design/workflow consideration, though, not an imperative.
One approach is to consider importance (perceived, that is). For instance, we give ID greater importance in the CSS, so that would be one thing to make consistent.
<div id="id" class="class"></div>
See where the leading space always separates it from whatever is before it, including the opentag? And notice that there is no white space around the
= sign. This is a general practice in the industry, and one to adopt, firmly.
Some attributes aren’t always needed. For example,
<label for="name">Name </label>
<input id="name" name="name" value="">
The above does not need a
type attribute since it defaults to
text if not specified. Since the
value attribute value is empty, even that attribute is not needed. It will be inserted by the browser when the user begins to type. These attributes would be redundant and only add to markup bloat. We generally want to economize whenever and wherever we can to keep our bandwidth down. When serving 100 000 pages a day or an hour that bandwidth has a price.
Bottom line, your example follows an ‘order of importance’ scheme that makes sense. When the
value attribute is present, I like it to be the last attribute in the element. If a
placeholder attribute is also present, it goes just before that, or last if the value is not present. That’s preference, of course, just like id before class before name…