The time when we will pay far more attention to the responsive markup than we do it now is already not too far off. So I consider that it is necessary to be well prepared in this question when the time comes, or even to have clear idea of what is it and what it is used for.
I would like to say at once that the markup of the responsive patterns requires some different approach, than the markup of statics. We will code a “fixed” pattern and it will work everywhere and under any conditions. However, when implementing it into the responsive pattern we can run into some difficulties such as: block sizes and indentions, fonts and, eventually, the created markup does not allow us to manipulate the blocks in a way it is required by the design pattern. It is necessary to think over all these questions before the creation of responsive markup.
Let’s move from words to deeds
I will not describe every pattern, as the realization of basic elements is very similar, and I will take only one, most interesting pattern №4 from this article
We do have:
1) Logo;
2) Menus in a right overhead corner;
3) A block, consisting of text and picture;
4) Three columns, with a particular content in each of them.
For basis I took the general model everywhere, with 80% width, but not more than 960px. I divided everything on 3 large blocks: top, main and content.
There is no problems with the logo, it was placed above and let it hang there all the time.
And through float: right we send the menu to the right, setting a size in 60% from a general width.
.item {
float: right;
width: 60%;
}
We will line up the menu items in a row through float: left, not forgetting to set them a size and indentions:
.list {
float: left;
width: 24%;
height: 50px;
margin: 0 0 0 1%;
}
*As I did not add any content, then I specify the height almost everywhere. In the real project it is possible to rely upon the amount of content.
We set a 50% width for a text block:
.m-text {
float: left;
width: 50%;
font-size: 20px;
font-style: italic;
line-height: 1.5em;
}
And I’ve sent the” picture” to the right through float: right, making a 40% width, in this way doing a supply in 10% between the blocks.
.m-image {
float: right;
width: 40%;
min-height: 360px;
}
*I did not want to calculate the sizes for border – radius, therefore a circle will be square ;)
Now we do three columns through the float:
.c-block, .c-article, .c-comment {
float: left;
width: 30%;
}
Below I will explain why I use float all the time.
In columns we place the content by ordinary blocks. I think, everything is quite simple here. Our pattern is ready and we begin the transformations.
Almost in all templates I used two types of screen sizes: 600 and 800 pixels, but it is not restricted to hang the necessary behavior on every pixel we like.
So, at a width of 800px we will have on the right places a logo, menu, text block and picture. We do not touch them. They have a rubber sizes, and at such resolution all will remain fully visible and readable. And the block with “banners” on the left, accepted a horizontal position and placed all its inner blocks in one line.
For this purpose at sizes @media screen and (min – width: 600px) and (max – width: 800px). We abolish it float and we stretch it on all width:
.c-block {
float: none;
width: 100%;
margin: 0 0 30px 0;
overflow: hidden;
}
For the inner blocks, vice versa, we apply float and set the necessary sizes:
.b-list {
float: left;
width: 32%;
margin: 0 0 0 2%;
}
.b-list:first-child {
margin: 0;
}
We leave the remaining two columns in vertical position, only stretching on the half of general width:
.c-article {
width: 48%;
margin: 0;
}
.c-comment {
width: 48%;
margin: 0 0 0 4%;
}
We get the result!
The next width is 600 pixels: @media screen and (max – width: 600px) A lot more transformations appear here.
At first we displace a menu beneath the logo, taking away at both float and letting it stretch in all width (in fact it is already not very large for 4th points).
.logo {
float: none;
}
.item {
float: none;
width: 100%;
margin: 30px 0 0;
}
We also stretch the block with text on all width and as usual take away the float:
.m-text {
float: none;
width: 100%;
margin: 0 0 40px 0;
}
And we put the block with the picture “beneath it”, removing float:
.m-image {
float: none;
width: 80%;
margin: 0 auto;
}
Picture’s width, as we remember, was set initially, but here we will change it a bit, for it to look better.
Banners. A block with banners again took the vertical position, and pictures stretched on all width. Thus we do not need to write code for this purpose, as they initially stand in a necessary variant.
And blocks with «the articles” and ” comments” now become the competent owners of all width of the layout:
.c-article {
float: none;
width: 100%;
margin: 0 0 30px 0;
}
.c-comment {
float: none;
width: 100%;
margin: 0;
}
Thus, we got the fully vertical structure of the page, and our layout became responsive.
Notes
The reasons I used float.
I myself love inline blocks more than anything. But as we know, inline blocks have a feature to take into account blanks in a width between the blocks . We even know how to work with them. But we need to remove only blanks, but not indentions between blocks, that is why the vast majority of methods are useless here.
Remained in a line-up font – size: 0; and comments between blocks.
font-size: 0;
All would be good in statics. And for Safari yet was hanged the display: table. But we have a «living” layout and very often scalable units (em) are used in such markup.
Because of the zero value of the parent’s font – size, we cannot apply scalable length units to the descendants, as they push off from the heritable font size and accordingly, in our case it is zero.
Though I didn’t use pixels for the sizes, I swept away this method and decided to do the example more versatile.
Comments between the blocks\physical deleting of blanks between the blocks.
I almost never use such methods, because it is hard to read the code. And in general, it is not always stable, if you forgot something everything will mix up.
In general, it is possible to use inline blocks, but in some cases it’s better to find a compromise
Styles are single and they are inherited!
As one could notice, in some cases we did not specify the properties for layout transformations and everything took the positions we wanted it to take. Initial styles of blocks were used.
It is needed to understand that by means of media queries we do not create the fundamentally updated version of the website with CSS, but we only change or redefine the styles written above. We operate only with the classes set initially. That’s the point. As I wrote in the introduction, an adaptive markup requires another approach. It is necessary to think over in advance about how our website will look, what and where will be displaced and transformed, what marking to write and what styles to use. Afterwards, all these points will help to shorten the amount of code at the change of structure.
Resolutions and their amount.
By means of media queries we can create a lot of transformations. But, as a rule, typical values are mainly used.
Mobiles:
240*320
320*480\240
480*800
Tablets:
800*600\480
1024*768\600
PC’s and notebooks:
From 1024 pixels (we won’t take into account the old ones).
So for each of these resolutions we can create ” the behavior” of marking. Thus, here it is necessary to remember about the inheritance of properties.
For example, here: @media screen and (min – width: 600px) and (max – width: 800px) we specified two values at once. Thus, we can do transformations, which to the best advantage will fit in the sizes of the screen from 600 to 800 pixels.
If in this case you will not specify the minimal size, then at writing of styles, for example, for 320 pixels, the styles written for max – width: 800px will be taken into account, in fact 320 obviously fitted in 800. Here are two ways to solve it:
1) To redefine properties for less resolutions (and why do we need a bunch of superfluous code?).
2) To use double values in media queries. Thus, we can conduct point transformations of our layout for determined screen sizes.
However, specifying of only one parameter can be justified. For example, when we need the same position of block\its sizes for all resolutions. We set these parameters one time and forget about it.
One can notice that at the change of browser window almost all transformations take place fluently. It can be done by adding of the following transition:
*{
-webkit-transition: all 0.3s ease;
-moz-transition: all 0.3s ease;
-o-transition: all 0.3s ease;
-ms-transition: all 0.3s ease;
transition: all 0.3s ease;
}
I did this only for the reasons of beauty. I don’t recommend doing that in the real projects.
Conclusion
Services I use for viewing in different resolutions (well for the sake of good order, it might be useful to someone).
http://quirktools.com/
http://viewlike.us/
Pattern examples
First, second, third, fourth, fifth.
Everything was checked in the following browsers: Chrome 17.0.963.83 m, Firefox 11.0, Opera 11.62, Safari 5.1.4, IE 9. All under Windows 7. And on several mobile devices.