October 2, 2012 at 21:21CSS principles
After a thorough analysis of HTML and CSS code, which is constantly being redone, we can draw conclusions that should help the reader in this difficult matter.
This article will not be tied to specific implementations and ready-made recipes in order to avoid the main problem of any CSS documentation - a couple of browser updates will be released during the writing of this article. And the advice will be simply useless.
I'll start with the basic: if in some browser the page does not display as intended, then you did something wrong. The creators of browsers, including IE6, are not fools. They thought with their heads before setting rendering rules and display methods. Any sliding element crawls due to a special interpretation of the combination of CSS properties, and not because "IE6 is buggy." Therefore, to solve the problem of a sliding element, you need to understand why it crawled there.
Let's touch on the concept of cross-browser compatibility.. What is the recipe for cross-browser layout? Layout immediately for all supported browsers. Only for all at once. The rule "I make it up for firefox, and then I will fix it for the rest" does not work. Go and then figure out who is to blame and what to do when a bunch of small CCSs have already been written. Of course, in this case, “dirty hacks” and conditional comments will be used. Of course, you can’t do without hacks at all, because there are still differences in rendering. What hacks do you need to remember? None. A minute search will yield a ton of solutions. First you need to determine the list of browsers (platforms, versions, devices), some fundamental decisions will not allow to expand the list at the end of development. Do not think that I advise you to go through the entire list after each change and check if anything has gone. The frequency of testing the application in different browsers is different. We begin to typeset in our favorite firefox with our favorite firefox. We periodically open IE7 to make sure that nothing went wrong. We open opera and safari and the ninth explorer a little less often. And very rarely - chrome.
By the way, this order of checking frequency in different browsers is easy to explain. Firefox Gecko, although authentic among popular browsers, is very close to WebKit and Opera Presto. Safari and Chrome use WebKit and are almost completely identical in rendering algorithms. The latest version of browsers is still poorly understood and these browsers remain the dark horse of our race — especially the latest IE. The penultimate IE complies well enough with standards, and does not cause much trouble, which cannot be said about the younger brothers thereof - the seventh (Trident V) and sixth (Trident IV) versions of the Internet explorer. A plus of the situation, I can note that these two versions are very similar to each other - if it looks good in IE7, little will have to be fixed in IE6. Moreover, there are fewer and fewer reasons to support the sixth and seventh explorer.
As for CSS templates and frameworks . The largest particle transferred from project to project should not be larger than the decision “how to arrange such and such elements in such and such a sequence”. Solutions like “three-column layout with pressed footer and horizontal menu” do not work due to the fact that they require the generation of heaps of uncontrolled and difficult-to-modify code for their solution. Any change to an existing third-party solution will cause a headache and lead to rewriting the code from scratch.
In addition to the above, it is worth considering the fact that such ready-made solutions do not in any way take into account subsequent CSS changes: changing the indentation of divs inside
I’ll separately mention the structure of css files and pictures . There are a thousand and one ways to correctly distribute pictures and patterns. But there are very few wrong ones.
Recall the most terrible of all the terrible ways - the only file
auto-sorters (iTunes, Windows Media Player, or the like) for another article. Another example of a no less awful, but more accurate placement and naming tactics for layout is this situation. Pictures are not located in one folder, but are located in subfolders as intended. All kinds of backgrounds are put in a folder
The logical question remains about the reuse of images for two different entities. An example is a design in which a line in the list of recent news has the same background as an element in the list of products. In this case, there are several solutions. For example, the background can be duplicated in two different folders
A skin algorithm for file locations is also common. In this case, the relative path to the pictures is indicated inside the css-files, and the style sheets and pictures are placed in one shared folder. For example, in the root of the site, inside the folder,
And in css files, backgrounds are indicated like this:
Instead of indicating absolute paths (from the root).
About validation and validators are worth mentioning in the context of the topic. Layout designers of Lebedev's studio correctly say that the best validator is a browser. If the page looks perfect in all kinds of browsers, then there is nothing to worry about. But it is worth remembering that the trump card in the valid code is an adequate reaction to future browsers. Immediately an example. During the formation of the third firefox, the author wrote a code in which a healthy bast of text with all kinds of markup was placed inside the link:
A click on an external link was processed, as a result of which the menu popped up and something did there that does not apply to the current topic. But after the release of Chrome, the author found that the above code does not work in the new browser. The problem was hiding in invalid code - paragraphs should not be placed inside links (like any other block markup elements).
From the documentation :
This article will not be tied to specific implementations and ready-made recipes in order to avoid the main problem of any CSS documentation - a couple of browser updates will be released during the writing of this article. And the advice will be simply useless.
I'll start with the basic: if in some browser the page does not display as intended, then you did something wrong. The creators of browsers, including IE6, are not fools. They thought with their heads before setting rendering rules and display methods. Any sliding element crawls due to a special interpretation of the combination of CSS properties, and not because "IE6 is buggy." Therefore, to solve the problem of a sliding element, you need to understand why it crawled there.
Let's touch on the concept of cross-browser compatibility.. What is the recipe for cross-browser layout? Layout immediately for all supported browsers. Only for all at once. The rule "I make it up for firefox, and then I will fix it for the rest" does not work. Go and then figure out who is to blame and what to do when a bunch of small CCSs have already been written. Of course, in this case, “dirty hacks” and conditional comments will be used. Of course, you can’t do without hacks at all, because there are still differences in rendering. What hacks do you need to remember? None. A minute search will yield a ton of solutions. First you need to determine the list of browsers (platforms, versions, devices), some fundamental decisions will not allow to expand the list at the end of development. Do not think that I advise you to go through the entire list after each change and check if anything has gone. The frequency of testing the application in different browsers is different. We begin to typeset in our favorite firefox with our favorite firefox. We periodically open IE7 to make sure that nothing went wrong. We open opera and safari and the ninth explorer a little less often. And very rarely - chrome.
By the way, this order of checking frequency in different browsers is easy to explain. Firefox Gecko, although authentic among popular browsers, is very close to WebKit and Opera Presto. Safari and Chrome use WebKit and are almost completely identical in rendering algorithms. The latest version of browsers is still poorly understood and these browsers remain the dark horse of our race — especially the latest IE. The penultimate IE complies well enough with standards, and does not cause much trouble, which cannot be said about the younger brothers thereof - the seventh (Trident V) and sixth (Trident IV) versions of the Internet explorer. A plus of the situation, I can note that these two versions are very similar to each other - if it looks good in IE7, little will have to be fixed in IE6. Moreover, there are fewer and fewer reasons to support the sixth and seventh explorer.
As for CSS templates and frameworks . The largest particle transferred from project to project should not be larger than the decision “how to arrange such and such elements in such and such a sequence”. Solutions like “three-column layout with pressed footer and horizontal menu” do not work due to the fact that they require the generation of heaps of uncontrolled and difficult-to-modify code for their solution. Any change to an existing third-party solution will cause a headache and lead to rewriting the code from scratch.
In addition to the above, it is worth considering the fact that such ready-made solutions do not in any way take into account subsequent CSS changes: changing the indentation of divs inside
.content, you cannot be sure that this will not cause a menu-level collapse in the old version of IE.I’ll separately mention the structure of css files and pictures . There are a thousand and one ways to correctly distribute pictures and patterns. But there are very few wrong ones.
Recall the most terrible of all the terrible ways - the only file
user.cssand daddy images with, sorry, shit there pictures. Some wise men guess that there should be some kind of structure in resources and name pictures with prefixes and suffixes. For example, " article-bg.png" or " product-li-bg.png". Let's step back from CSS and imagine a hard drive of such a developer. Movies are in the same folder, but they name such files, let's say: " alien_life_documental_discovery.avi" or " pelmeni_vs_pyatigorsk_kvn_2008_polufinal.avi". With a large number of files, navigating in this small heap is impossible.Let us leave a polemic on the topic of media libraryauto-sorters (iTunes, Windows Media Player, or the like) for another article. Another example of a no less awful, but more accurate placement and naming tactics for layout is this situation. Pictures are not located in one folder, but are located in subfolders as intended. All kinds of backgrounds are put in a folder
images/bgs, icons in a folder images/icons. This method is unsuccessful due to incorrect resource classifications. Separating pictures not by similarity of use, but by logical similarity will bring great practicality - all pictures belonging to the news should be put in a folder images/newsand called " bg.png", " li.png", " first-item.png". This arrangement predisposes the sharing of resources, as a result of which the resources are easily controlled.The logical question remains about the reuse of images for two different entities. An example is a design in which a line in the list of recent news has the same background as an element in the list of products. In this case, there are several solutions. For example, the background can be duplicated in two different folders
articlesand products. This should be done for the same reason that the minimum number of letters in the password for the user and the minimum length of the article title should not be one variable. Or, as an option, rename the entity to a more general one and create a folder not articlesand news_items, but somehow more general - publicationsor something like that.The dilemma of choosing a name for a common entity between two entities is tense. In the case of the same type of two different entities, they can be generalized by some criterion, because the designer has already done this. The case of the meager design of the "main page and one internal" we do not consider as clinical. A skin algorithm for file locations is also common. In this case, the relative path to the pictures is indicated inside the css-files, and the style sheets and pictures are placed in one shared folder. For example, in the root of the site, inside the folder,
themescreate folders stylesheetsand images. This in no way affects the folder structure inside the folder images.Please note that some frameworks provide only this way of integrating your own styles. Therefore, knowledge about the framework before starting the layout is necessary. But this is a completely different story. And in css files, backgrounds are indicated like this:
background-image: url(../images/articles/bg.png)
Instead of indicating absolute paths (from the root).
background-image: url(/images/articles/bg.png)
About validation and validators are worth mentioning in the context of the topic. Layout designers of Lebedev's studio correctly say that the best validator is a browser. If the page looks perfect in all kinds of browsers, then there is nothing to worry about. But it is worth remembering that the trump card in the valid code is an adequate reaction to future browsers. Immediately an example. During the formation of the third firefox, the author wrote a code in which a healthy bast of text with all kinds of markup was placed inside the link:
Lorem ipsum dolor set...
A click on an external link was processed, as a result of which the menu popped up and something did there that does not apply to the current topic. But after the release of Chrome, the author found that the above code does not work in the new browser. The problem was hiding in invalid code - paragraphs should not be placed inside links (like any other block markup elements).
From the documentation :
One possible cause for this message is that you have attempted to put a block-level element (such as "" or "
") inside an inline element (such as "", "", or "").
В результате чего код был переписан с учетом требований валидного кода и проблемы самоустранились.
В итоге можно сформулировать что стантарты нужно соблюдать до тех пор, пока сами стандарты не препятствуют достижению целей и вариантов написать код валидно нет. Иными словами соблюдайте стандарты всегда и нарушайте это правило будучи уверенным в своей правоте.