Quite obviously slicing for an unpopular site with few pages isn’t the same as coding and supporting of huge popular portal.
So let’s try to review some nuances and solutions which an HTML coder should always be ready for.
A few advises
An HTML page and style files code should be well structured and should have an ability of extending without any problems. Every site, and especially large and popular site, tends to growing and expanding.
Generally the bigger is the project the harder it is to provide changes to pages structure. This means that from the very beginning of coding you should be ready for permanent changes, adding new blocks and elements to the page in future.
Correct coding should be laconic
You should understand that sometimes page services are overcharged. That is why you should work scrupulous on the generated code trying to make it maximum simple and laconic. A few kilobytes saved with extra spaces or shifts in a large css file will not influence user traffic much but this would make the work of an overcharged server much easier.
You should consider standards and features
One more feature of large sites development is that web experts work is often conducted in a team. In this case we are not talking about very small teams such as designer, slicer (optimizer) and programmer, but about big teams which include several slicers.
Each developer has a style of coding and slicing which has developed over the years and it will be very difficult and unnecessary to change it for some abstract purposes. Meanwhile, development of the general style of coding is a necessary condition for the effective decision of the general problems. If there is a possibility you can make the list of effective and convenient rules for all members of the team and strictly adhere to this set. For example, the rule of comments placing in the code which certainly is in the international “rules” of professional coding too.
It is difficult and dangerous to provide global changes
As it was already mentioned earlier – the base pages of some services are exposed to serious overcharging. Careless modification of working files of the project can be negatively reflected on the speed of all system, and the error admitted during such changes is capable to become critical.
For example, after entering the necessary changes into a styles file the set of client programs starts to request it again and again, creating the overcharge. Compulsory caching of such files which allow to lower the quantity of inquiries actually is a two-edged sword – global changes which have already occurred in the HTML page code get to the user, but thus styles in users browser were not updated yet. As a result, thousand of users for a quite long time receive completely not what they expected, and it is very unpleasant… Additional caching of the formed pages on the server side will make it even worse but it is also not a rarity.
It is still possible to rename, remove or transfer the styles file to any other folder, and do not correct the link in the document. Then not only users, but also a server which will receive a lot of inquiries to a nonexistent file will be “grateful” to you.
Compatibility in different browsers
Working on site coding, it is necessary to take into consideration a big quantity of existing browsers. The statistics reflect the preferences of an audience approximately and it is necessary to be guided by the highest positions in this rating (for example, Internet Explorer 6 or its 7th version). You should not forget about other browsers also, even in spite of the fact that working out under obsolete browsers occupies a lot of extra time and work.
Some guidelines for page coding
Before partitioning a page and specifying the parts for the templates, a slicer should find out what page components will repeat from service to service without changes. Traditionally, such elements are header, footer and special panels of navigation between services in certain cases. It will help us to cache repeating parts of page better and the site will work much faster.
It is quite logical for taking out the listed components into separate templates of global level which would be easily connected to all pages, instead of to duplicating their code for each service separately. While preparation of such templates it is necessary to give particular attention to preliminary optimization of a code and testing. The better you test and improve structure, the better results it will give further. Optimization means unconditional moving of all styles (tag style = “”) into separate CSS file, disposal of extra spaces and carry-overs of lines, displaying of used images with the help of the same CSS technology.
Correct CSS use at coding
As we have studied the distribution and creation of global templates now it is time to talk about how to optimally put Cascading Style Sheets into the context of large-scale projects.
First of all, it is necessary to refuse the inline styles. It is obvious that it will help to reduce the size of pages considerably. To save more user traffic using the caching advantages we will take out all CSS code into an external file. It is necessary to notice that in certain cases usage of the inline styles is possible due to some reasons. In such situations working out on optimization of the received table is also required.
As we have already found out earlier, all our pages have general components, hence, for the css description of these components it is necessary to create a separate external file of styles. You can name it, for example, style.css.
<link rel="stylesheet" type="text/css" media="all" href="http://css/style.css" />
Also it would be correct to place the general properties for all pages to this file – properties of a background, the sizes and colors of fonts, spaces, colors of links.
We will admit the following conceptual division of pages is applied on our portal:
- pages of the user blogs;
- pages of auxiliary services, such as information search, questionnaires of acquaintances, ratings of participants;
- system pages (for example, page options, adding of messages on a site);
So how should we connect Cascading Style Sheets of pages in this case? It will be convenient to assign a file for each type of pages (one css for diaries, another – for services and for system pages). As a result only four files are responsible for displaying of all pages of the portal.
On one hand, it is strange to force the user to load a huge amount of rules but on the other hand – the quantity of inquiries to a server to CSS styles files is greatly decreases. Single files are loading faster, earlier loaded files get undertaken from a cache of a browser and it is not necessary to waste time on loading of styles for the next service.
Ways of css optimization
If we have to deal with large css-files due to project size, it would be not superfluous to work on their optimization. We will consider some ways of css optimization:
- We throw out comments, spaces, transfers of lines (why should we keep them in the final product);
- We reduce codes of colors, for example it is possible to write down white color both #ffffff and #fff (it will not play the big role, but still);
- We reduce css-properties (background, font, list-style, margin, padding, border), it often distinguishes the professional from the beginner, therefore this point is important doubly;
- We unite selectors with identical properties (beginners often suffer this problem– a very big quantity of unnecessary class = “” and id = “”);
- Whenever possible, we make paths to files with images easier (it will be useful for SEO-optimization because pictures are content too);
Use of these not tricky rules allows to reduce the size of a big css file by 30-60 % which is much. However to adhere these recommendations in everyday life is not always convenient. Manual optimization is justified by preparation of a global css file, and for constantly changeable additional styles it would be great to automate this process. Special services and programs will help us with it.