Today, milling one layout, I seem to have invented another interesting method of vertical alignment of the block relative to the parent. It is
not based on turning blocks into table cells and does not use the css
position property.
Requirements
- The initial height of the parent unit must be known;
- A child unit can have an arbitrary size in both height and width.
Opportunities
- Works in IE6 +, O9 +, FF2 +, webkit;
- True vertical-align alignment with all
valid values ;
- The same behavior in all browsers (minor deviations under some conditions in IE6 will be specified below);
- When a child unit grows above the “daddy”, the parent unit expands;
- Not a single gram of JavaScript.
')
So, to begin with, let's look at the
blank that I want to use for the story.
We have a .container block of a fixed height of 200px and a block with text inside it, although for definiteness we need to align it in the middle of the parent container. I also added regular text below, which, with a small width of the window, is overlapped with text from the container. We will also get rid of this unpleasant effect.
Transformation number one
Know how of my method is that instead of specifying the actual height of the .container block, we specify the
line-height at the same 200px, and make the child block as a built-in block (
display: inline-block ;). The biggest trouble that awaits in the whole method is that the line-height value is inherited to the child block and for it you have to set it again:
.container {
line-height: 200px;
}
.block {
display: inline-block;
line-height: 1.2;
vertical-align: middle;
}
And we get
this page , already working in IE8, O9 +, FF3 +, webkit. As I promised, when the window is reduced to a size where the child becomes taller than the parent, the parent will stretch. I purposely draw attention to this, since this behavior can be very, very useful in real layouts, when a small headline looks better in the middle of the line, and a large one should push the next content further.
Transformation number two
Having achieved such a result, I certainly was delighted, but naturally, I did not believe in success until I checked in 6 and 7 and, as it turned out, for good reason. In fact, not everything is as bad as it seems. I knew the answer to the first question that I had beforehand: the old IE cannot apply the value of display: inline-block to the initially block elements. Said and done, <div class = "block"> without regret was replaced by <span class = "block">
But in this case it was a confusion and I still had what is shown in the picture on the left:

Having scratched my turnip, I decided for some reason to check what would happen if I put a real inline element after an inline-block element, say text. Oddly enough, this had the desired effect and I got what is in the picture on the right. Well, well, let's write one more IE into the piggy bank of glitches: a single inline-block element is forced to become a block element. It remains only to pack a new inline element so that it does not interfere with other browsers and does not take up space. It turned out something like this:
< style type ="text/css" >
.iefix {
display: none;
}
</ style >
<!--[if lte IE 7]>
<style type="text/css">
.iefix {
display: inline-block;
width: 0;
overflow: hidden;
}
</style>
<![endif]-->
< div class ="container" >
< span class ="block" >
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s
</ span >
< span class ="iefix" > </ span >
</ div >
* This source code was highlighted with Source Code Highlighter .
Leaving .iefix to a purely inline element also failed, for width and overflow are applicable only to block elements. The same option earned in un6 without changes.
Now the
example has worked in all browsers that interest me with layout except FF2. It is worth noting only one glitch in IE6. When the size of an element with text is reduced to the size of the largest word (or another element that cannot be split into several lines), IE6 still moves the element of zero width .iefix to another line, causing the height of the whole block to increase by 200 pixels (the value of the line- height):

Transformation number three
Well, for a snack, there was FF2, which, as you know, does not understand inline-blocks, but can emulate this through the
display value
: -moz-inline-stack; . The -moz-inline-stack property requires that its contents be wrapped in another block, so the HTML code grows a bit here:
< div class ="container" >
< span class ="block" >
< span >
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s
</ span >
</ span >
< span class ="iefix" > </ span >
</ div >
* This source code was highlighted with Source Code Highlighter .
It is worth noting that FF2 did not want to transfer the text, so I had to explicitly ask the block with the text width: 100%; In principle, this is not so scary, most likely the real page will imply specific values for the width of the text.
The result is a
great way to vertical alignment in all popular browsers.