The controversial rules of simple layout

This article is primarily a response to the recently published article: "Simple rules for simple layout . "
The author invited me to write an answer, to express my opinion on these examples and recommendations; I also intend to use this invitation below. (Read the original article before you go under the cat - a must!)

Quotes highlighted all the allegations that immediately under them I was going to refute.

Well, without undue delay immediately proceed:

Things are obvious, but I haven’t found an article that brings them together.

The silent question froze on the tip of the pen: Was the author looking for it? I am sure not, especially the majority of the technicians recommended in the article are very controversial, and have often caused a lot of discussions, therefore they are not entitled to be called “bug fixes”.

As for the recommendations themselves:

<!-- news --> <div class="news"> <div class="item"> <span class="date">16.07.12</span> <a href="#" title="" class="title"><strong>  </strong></a> <p> </p> </div> <div class="item"> <span class="date">16.07.12</span> <a href="#" title="" class="title">  </a> <p> </p> </div> <div class="item"> <span class="date">16.07.12</span> <a href="#" title="" class="title">  </a> <p> </p> </div> 

')
The news block, I don’t know how you are, but I don’t see anything here ... the standard page markup ... what extravagance the author tried to leave, I didn’t understand, it looks like this example in the “After” style lacks the example “Before” .
But there is a bad style here:

Pay attention to the universal class item. Everyone is free to call him differently, say box, it doesn’t matter, the item seems to me absolutely neutral and understandable for all who have to work with the code in the future - this is just a block from the list of others like it.

Such universality is a very bad recommendation, precisely because this class says nothing about what kind of entity it is, what it is used for, and as a result, much more than one such item can appear in the final project, which will complicate project maintenance , I'm not talking about what will happen if several such, unrelated classes meet in the same namespace.
Recommendation: Read Steve McConnell's book “The Perfect Code”, there besides this advice you will find many more interesting observations, ideas, good practices, etc.

You can also notice a comment in front of the general block, duplicating the class name. This may seem redundant, but in practice it greatly facilitates orientation in the code.

It is very mediocre, I would not call it at all with advice, technology and anything else, in my personal opinion, it is really “redundant”, it is perhaps much more profitable to leave a comment right after the closing block, with information about which particular block we are just closed, no more:

 </div><!-- /news --> 

... put down tabindexes and number or give clear names to the elements of the form.

Do not number, let's understand the names, I already wrote about this.

It is now considered to be good practice to connect scripts before the closing body, with which I cannot but agree, there is nothing wrong with that. It is also recommended to make static calls to functions that do not change from page to page in a separate file.

In a good tone? Honestly, I haven't heard anything like that, if I'm wrong, correct it, but we are dealing with a standardized language? And as for me, there is nothing wrong with sticking to a standard and describing all cascading tables and plug-in scripts in the header of the document, in the “head” selector specially reserved for this, or are the new standards already providing for the “footer” selector?

Code Logic - General Recommendations

I will not say anything here, some tips are good, some are somewhat controversial, but not enough to inflate discussions with them, except perhaps to mention:

• The names of the main folders of the project root and page names should be standardized.

This should be done so that people who have access to the hosting by chance, or in some other way, without being either the owner or the service personnel, could easily find the most critical places of the system.

Standardization is of course necessary, but it’s not necessary to call them as is customary, you can solve all this at the project level, document it and then follow the accepted standards.

A little bit about CSS

It’s not for me to teach anyone how to draw up a style sheet, I’ll only show the well-known method, which is relatively rarely used, but it increases the readability of CSS to the beyond high and eliminates the need to use the Ctrl + F spell.

At first glance, good advice, but again, very much so controversial, many times both its advantages and not less important disadvantages were discussed, I would not recommend using such a structure.

If you find it difficult to understand your CSR file, it may be a much better solution to pick up, or set up your editor so that he builds such a tree, but when clicked, for example, opens it.

But personally, I do not see the difficulties in Ctrl + F by the name of the class (identifier), at least it is easier than to search in the line by the name of the property, or more so by value.