When dealing with front-end stuff, we try to follow simple and sufficiently comprehensive maxims that make all our work easier — for back-end developers and for future code supporters.<\/p>\n\n\n\n
Furthermore,\u00a0good code allows us to sleep well and not be ashamed of the projects we release.<\/p>\n\n\n\n
This\u00a0means that you should dig with a shovel but not use it to hold up the roof.\u00a0We cannot\u00a0just\u00a0follow\u00a0a “here,\u00a0I fixed it” approach. For example, if you have tabular data, you may use tables rather than just\u00a0cramming\u00a0the data\u00a0inside a bunch of divs or list-items. Assuming of course that\u00a0there is not a strong need to use those divs. If you want to\u00a0put form elements in a\u00a0horizontal block you should use div, not paragraph. And you should not act against your\u00a0better judgement\u00a0by settling for\u00a0an\u00a0“Oh, it looks fine with paragraph anyway!” attitude.<\/p>\n\n\n\n
If you have five tables and one of them is green and four are blue, you don’t have to reinvent the wheel.\u00a0Similar blocks should be coded the same way and should be managed with CSS selectors. You can do this, for example,\u00a0if you have two similar blocks — a news widget with 5\u00a0older news items\u00a0and an interview block with 3 fresh topics —\u00a0and each of them contains a few content items with title, image, text and a\u00a0“read more” link.\u00a0<\/p>\n\n\n\n
The only difference between the two\u00a0is that news items\u00a0have a blue background and the interviews\u00a0have green, or perhaps that the\u00a0news images are floating to the left and the interview block has images floating to the\u00a0right. Obviously, you don’t need to make two different blocks. A class “block” could accommodate all similarities\u00a0in both elements. And by setting specific classes for each block (“block news” and “block interviews”), you will be able to accentuate the individuality of any of them (just don’t forget to use hierarchical selectors for their children, e.g., div.block.news .item img.thumb).<\/p>\n\n\n\n
This kind of approach, moreover,\u00a0allows you to appropriately\u00a0handle\u00a0various options, such as\u00a0“when I click here, I want this block to expand and show additional info.” Switching the “expanded” class for the\u00a0parent block (div.block) and CSS rules for div.block and div.block.expanded (yep, it’s the same for children: div.block .item and div.block.expanded .item) makes it possible to switch the block state with a single jQuery string. Furthermore, you will need only one\u00a0click handler, not one for each block.<\/p>\n\n\n\n
You\u00a0should also\u00a0attempt to\u00a0make blocks as flexible as possible even if\u00a0this is not\u00a0necessary for your\u00a0immediate\u00a0task. No one knows how the layout may change tomorrow. A block with a width of\u00a0400px will demand 600px (or even full-page width) considering that 400 is too narrow,\u00a0or else\u00a0the right column of a two-column layout will realize\u00a0the uselessness of its existence\u00a0and quit, leaving\u00a0the blocks in the left\/center column to do all the work alone.\u00a0In other words,\u00a0if your stuck with a width of\u00a0400px, you’ll have to\u00a0work a bit to make the page look good. But if you just widen the column, all children blocks can happily stretch out\u00a0in all the\u00a0new space.<\/p>\n\n\n\n
There once existed an agreement\u00a0with devs to\u00a0avoid overlaping\u00a0tasks and to give them ability to rule IDs. Front-end people are not greedy, in my humble opinion, so we are fully\u00a0onboard with using classes. <\/p>\n\n\n\n
First, it\u00a0limits namespace. <\/p>\n\n\n\n
Second, it prevents the sudden appearance of a second “menu” block,\u00a0which\u00a0an hour ago you could not\u00a0even imagine popping up on the page. <\/p>\n\n\n\n
And third, it simplifies the conception of CSS selector priorities, so\u00a0you just need to think about the selector length but don’t have to check if there any hidden IDs that override your recent style rule.<\/p>\n\n\n\n
It is a well-established principle to use comprehensive names, and class names\u00a0are no exception. I will never prefer a\u00a0class name like\u00a0“div.nb1” over “div.news-block.first.” Front end is not Assembler. So you don’t need to save letters. Treat all class names with respect, and remember that a class name like “nbvw23” is not going to win anyone’s respect.<\/p>\n\n\n\n
As our physics lecturer used to say, “Do not put crocodiles and bus stops together.” We consider inline styles to be a sign of cowardice and a crime against the conscience\u00a0(tags like “center” and other\u00a0presentational tag attributes look like a deal with the Devil). <\/p>\n\n\n\n
All markup should be done in a way that allows\u00a0a complete\u00a0change\u00a0in your page’s appearance\u00a0by changing only\u00a0CSS\/JS files\u00a0without any interference in HTML. A task with 5 templates with identical content\u00a0but different “faces” will be resolved with\u00a0one<\/em> HTML file and 5 stylesheets (or even 5 body classes for on-the-fly template switching). Inline styles (as with\u00a0any\u00a0visuals in an\u00a0HTML file\u00a0that has priority above external\u00a0CSS rules) make such things impossible because you must\u00a0alter the template itself to change\u00a0the appearance.<\/p>\n\n\n\n It’s\u00a0a boring and thankless task to search for a closing tag in a long chain of\u00a0identical closing tags and tab stops. You can rely upon a faultless eye and count down\u00a0through the\u00a0tab stops within the\u00a0opening tag and look for the very first closing tag with the same\u00a0number of stops. <\/p>\n\n\n\n But this will only work if you can\u00a0ensure that all your tab stops\u00a0are correct :) One mistake and you may go on a wild-goose chase:\u00a0hunting for an\u00a0extra closing tag in a thousand lines of code (additionally your page will look like a total mess). Adding a comment with a class name to the closing div will\u00a0save you\u00a0from this headache.\u00a0It\u00a0will ensure that you\u00a0have an\u00a0individual closing tag that\u00a0is not hard to find. TextMate snippets will help you out with that.<\/p>\n\n\n\n There is a famous developers joke: “Zeroize your variables!” A pluralistic company of browsers\u00a0that has majority ownership of an Internet LLC generally consists of a group of quite self-loving characters. Each of them,\u00a0to\u00a0varying degrees,\u00a0will embody the phrase,\u00a0“There are two kinds of opinion: mine and wrong!” <\/p>\n\n\n\n But we ourselves are the ones\u00a0who suffer from this. To minimize our pain, we’re trying to avoid this\u00a0by using reset.css. It forces us to reset all default styles, so we make a crowd first and then we paint everyone out.<\/p>\n\n\n\n The slogan “Less is more” is\u00a0neither new or original — but it is effective.\u00a0We are trying to reach our\u00a0goals with a minimum of words. As a rule there\u00a0is more than one way to resolve a task, so we prefer\u00a0an approach\u00a0with\u00a0fewer lines of code (without, of course, diminishing\u00a0appearance, flexibility and functionality). <\/p>\n\n\n\n The less you write, the easier it is to comprehend. And it looks prettier :). One more quote from that professor: “The correct formula is always beautiful. If a formula has no beauty, it’s wrong for sure. But if a formula is beautiful, it does not mean that it is already correct.” So beauty and laconism must be coupled\u00a0without detriment\u00a0to the\u00a0appearance\u00a0and functionality.<\/p>\n","protected":false},"excerpt":{"rendered":" When dealing with front-end stuff, we try to follow simple and sufficiently comprehensive maxims that make all our work easier — for back-end developers and for future code supporters. Furthermore,\u00a0good code allows us to sleep well and not be ashamed of the projects we release. 1. Use elements with intended applications. This\u00a0means that you should dig with…<\/p>\n","protected":false},"author":8,"featured_media":3759,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Dmitry Pliska"],"class_list":["post-20","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/20","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":22,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/20\/revisions"}],"predecessor-version":[{"id":14120,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/20\/revisions\/14120"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/3759"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=20"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=20"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=20"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}5. Structural comments.<\/strong><\/h2>\n\n\n\n
6. Using reset styles.<\/strong><\/h2>\n\n\n\n
7. Write less, do more \u00a9<\/strong><\/h2>\n\n\n\n