CSS problems. Part 2
Continuing the translation of the article “CSS Problems. Part 1 " .
Perhaps let's start with the fact that simpler. When to use height: 100% ? In fact, the question often sounds a bit different: “How can I make my page fill the entire height of the screen?”. After all the truth?
To answer it, you need to understand that height: 100% is equal to the height of the parent element. This is not the magical "height of the whole window." So, if you want your element to occupy all 100% of the height of the window, then setting height: 100% will not be enough.
')
Why? But because the parent of your container is the body element, and its height property is set to auto by default; which means its height is equal to the height of the content. Of course, you can try to add height: 100% to body, but this will not be enough either.
Why? And that's because the parent of the body element is the html element, which also has its height property equal to auto and it also stretches to the size of the content. And now, if you add height: 100% to the html element, everything will work.
It became clearer? The root element html is actually not the topmost level on the page — it is the “viewport”. For simplicity, we will assume that this is a browser window. So, if you set the height: 100% to the html element, then this is the same thing to say - become the same height as the browser window.
We summarize the information obtained in a small piece of code:
Is done. If you are interested in delving into the topic of how the viewport works, I highly recommend an article from PPK .
Recently, Roger Johansson described a problem with height: 100% , which manifests itself when height is not set on the parent element, but min-height is specified. I do not want to delve into what was said in the article, but go straight to the conclusions. You need to set the height: 1px for the parent so that the child can take all the height specified in the min-height.
An example on jsFiddle .
In more detail, with this question, you can read the article by Roger Johansen (Roger Johansson) .
Now let's deal with width: 100% . For a start, a small clarification: by setting the width: 100% property, we want our element to fill the entire width of the parent element. Everything is standard.
Let me tell you a little secret. width, for this property is not a very appropriate name. The width property is not the absolute size of the element, but the size of the content of the element and this is a huge difference.
If you add padding and / or border to an element with width: 100% , then it will no longer fit into the parent element. Because padding and border appeared and that's why width should have been called content-width. And now, please look at an example that demonstrates the above.
An example on jsFiddle .
Suppose a parent width is 25em, and a child element is 100% (of the parent width) and it also has a padding equal to 1em (1em on the right and 1em on the left, at the sum of 2em horizontal) and a border of 0.5em in size (0.5 em on the right and 0.5 on the left, at the amount of 1em horizontal ), which ultimately gives us 25em (100%) + 2em + 1em = 28em.
There are 4 possible ways to solve this problem. The first and probably the best way is to avoid the width: 100% property, especially since in this case it is absolutely useless. If the child element is block, then it will occupy the entire width of the parent automatically (no problems with padding and border). But if we work with an inline-block element, then we will not be able to solve this problem so easily.
We can replace width: 100% with a static size. In our case, 25 - (2 + 1) = 22em. Needless to say - this is a bad decision, because we need to calculate the width manually. Let's go the other way!
The third way is to use calc () to calculate the width: width: calc (100% - 3em) . But it also does not fit. First, we still need to calculate the padding + border dimensions. Secondly, calc () is poorly supported by browsers (does not work in IE 8, Safari 5, Opera 12, the native Android browser).
Idea number four is to use the box-sizing: border-box property. It changes the algorithm for calculating the width and height of the element so that they take into account the padding and border properties. The great news is that box-sizing has good browser support (IE8 +, Opera 7+). And for all other browsers you can use polyfill .
Conclusion: do not use width: 100% without box-sizing: border-box .
All elements on the pages are positioned in three planes: in addition to the vertical and horizontal axis, there is an additional axis Z (depth). At first, everything looks very simple - elements with a large z-index are above elements with a smaller z-index. Unfortunately, everything is much more complicated. I am sure that z-index is the most difficult css property in its entire history. I am also sure that the problems associated with the z-index are more common when working with css. I hope that we will enlighten possible ways to solve them.
To start. The z-index property has no effect on static elements. To be able to move an element along the Z axis, we need to change its positioning to relative, absolute or fixed.
It is important to understand in z-index that not all elements in the DOM tree are placed on the same level. This means that changing the z-index of an element to a very large value does not guarantee that it will be placed in the foreground. This is called the overlay context.
In simple terms, the overlay context is a kind of group based on a single html element, in which all child elements get the same position in the context and the same z-index. Changes to the z-index of an element can cause it to overlap other elements, as you need. Here are the elements in a single overlay context (bottom to top):
So, we looked at the basics of z-index, understanding which will save you a lot of time, believe me. Unfortunately, they are not enough. Then everything would be too easy.
The point is that each overlay context has its own Z axis. For example, element A in context 1 and element B in context 2 cannot interact via z-index. This means that element A, as part of the overlay context that is at the very bottom of the overall overlay context, can never block element B of another context that is above the level, even with a very large z-index value.
But worse. The html element creates a root context overlay. Then, each non-static-positioned element with the z-index property not equal to auto also creates its own overlay context. Nothing new. But this is where everything starts to collapse: some non-context related css properties also create new contexts. For example, the opacity property.
That's right, the opacity property creates a new overlay context. The same is done by the transform and perspective properties. Although it makes no sense, does it? For example, if you have any element with opacity less than 1 or with any transformation, you could potentially have a problem.
Unfortunately, every problem with a z-index has its own context (not a pun) making impossible a universal solution.
Let's summarize the above:
In the subject, I also recommend reading What is the One Told You About Z-index from Philip Walton and the official css specification .
As it seems to me - this is one of the css glitches, which steals the greatest amount of time to figure out what the matter is. We can say that it looks something like a bug with z-index. Be that as it may, the collapse of indents is when the upper and lower indents of two elements collapse into one (the largest of the two).
Fortunately, as a rule, this behavior is expected. Perhaps that is why it works this way (as stated in the css specification). However, sometimes you do not want the vertical indents to collapse. To understand how to avoid this, we will first see why this happens. Indent collapse can occur in three different cases.
When two adjacent elements have vertical indents - they collapse to the largest of them. There are several ways to prevent a collapse:
The example on jsFiddle illustrates the work of fixes.
Usually, the top margin of the parent and child elements collapse to the largest. Similarly, it works for the last child and bottom indents. To solve this problem, there are also several ways. Most of which consist in adding one of the following properties to the parent element:
The example on jsFiddle illustrates the work of fixes.
When an empty block has no boundaries, paddings, heights, its upper and lower indents collapse into one. Anyway, using empty blocks is a bad practice, so this is not common.
Unfortunately, only the tip of the iceberg of bugs and hacks css is described here. But these are really those that occur more often than others, but there are still many things such as browser incompatibility, vendor prefixes, the specificity of selectors, cascades and inheritance, and much more.
I would also recommend to read the following articles and sites:
I hope the article has helped to understand some things that can save you from future problems.
When to use width / height equal to 100%?
Height: 100%
Perhaps let's start with the fact that simpler. When to use height: 100% ? In fact, the question often sounds a bit different: “How can I make my page fill the entire height of the screen?”. After all the truth?
To answer it, you need to understand that height: 100% is equal to the height of the parent element. This is not the magical "height of the whole window." So, if you want your element to occupy all 100% of the height of the window, then setting height: 100% will not be enough.
')
Why? But because the parent of your container is the body element, and its height property is set to auto by default; which means its height is equal to the height of the content. Of course, you can try to add height: 100% to body, but this will not be enough either.
Why? And that's because the parent of the body element is the html element, which also has its height property equal to auto and it also stretches to the size of the content. And now, if you add height: 100% to the html element, everything will work.
It became clearer? The root element html is actually not the topmost level on the page — it is the “viewport”. For simplicity, we will assume that this is a browser window. So, if you set the height: 100% to the html element, then this is the same thing to say - become the same height as the browser window.
We summarize the information obtained in a small piece of code:
html, body, .container { height: 100%; } Is done. If you are interested in delving into the topic of how the viewport works, I highly recommend an article from PPK .
What if the parent element is set to the min-height property, not the height?
Recently, Roger Johansson described a problem with height: 100% , which manifests itself when height is not set on the parent element, but min-height is specified. I do not want to delve into what was said in the article, but go straight to the conclusions. You need to set the height: 1px for the parent so that the child can take all the height specified in the min-height.
.parent { min-height: 300px; height: 1px; /* Required to make the child 100% of the min-height */ } .child { height: 100%; } An example on jsFiddle .
In more detail, with this question, you can read the article by Roger Johansen (Roger Johansson) .
Width: 100%
Now let's deal with width: 100% . For a start, a small clarification: by setting the width: 100% property, we want our element to fill the entire width of the parent element. Everything is standard.
Let me tell you a little secret. width, for this property is not a very appropriate name. The width property is not the absolute size of the element, but the size of the content of the element and this is a huge difference.
If you add padding and / or border to an element with width: 100% , then it will no longer fit into the parent element. Because padding and border appeared and that's why width should have been called content-width. And now, please look at an example that demonstrates the above.
An example on jsFiddle .
Suppose a parent width is 25em, and a child element is 100% (of the parent width) and it also has a padding equal to 1em (1em on the right and 1em on the left, at the sum of 2em horizontal) and a border of 0.5em in size (0.5 em on the right and 0.5 on the left, at the amount of 1em horizontal ), which ultimately gives us 25em (100%) + 2em + 1em = 28em.
There are 4 possible ways to solve this problem. The first and probably the best way is to avoid the width: 100% property, especially since in this case it is absolutely useless. If the child element is block, then it will occupy the entire width of the parent automatically (no problems with padding and border). But if we work with an inline-block element, then we will not be able to solve this problem so easily.
We can replace width: 100% with a static size. In our case, 25 - (2 + 1) = 22em. Needless to say - this is a bad decision, because we need to calculate the width manually. Let's go the other way!
The third way is to use calc () to calculate the width: width: calc (100% - 3em) . But it also does not fit. First, we still need to calculate the padding + border dimensions. Secondly, calc () is poorly supported by browsers (does not work in IE 8, Safari 5, Opera 12, the native Android browser).
Idea number four is to use the box-sizing: border-box property. It changes the algorithm for calculating the width and height of the element so that they take into account the padding and border properties. The great news is that box-sizing has good browser support (IE8 +, Opera 7+). And for all other browsers you can use polyfill .
Conclusion: do not use width: 100% without box-sizing: border-box .
How not to mess with z-index.
All elements on the pages are positioned in three planes: in addition to the vertical and horizontal axis, there is an additional axis Z (depth). At first, everything looks very simple - elements with a large z-index are above elements with a smaller z-index. Unfortunately, everything is much more complicated. I am sure that z-index is the most difficult css property in its entire history. I am also sure that the problems associated with the z-index are more common when working with css. I hope that we will enlighten possible ways to solve them.
To start. The z-index property has no effect on static elements. To be able to move an element along the Z axis, we need to change its positioning to relative, absolute or fixed.
It is important to understand in z-index that not all elements in the DOM tree are placed on the same level. This means that changing the z-index of an element to a very large value does not guarantee that it will be placed in the foreground. This is called the overlay context.
In simple terms, the overlay context is a kind of group based on a single html element, in which all child elements get the same position in the context and the same z-index. Changes to the z-index of an element can cause it to overlap other elements, as you need. Here are the elements in a single overlay context (bottom to top):
- Background and borders of the context element
- Child imposition contexts with negative z-index (smallest first)
- Non positioned items
- Positioned elements with a z-index value of auto or 0
- Positioned elements with a positive z-index (each following in order is located higher than the previous one, with z-index being equal)
When the situation becomes unpleasant
So, we looked at the basics of z-index, understanding which will save you a lot of time, believe me. Unfortunately, they are not enough. Then everything would be too easy.
The point is that each overlay context has its own Z axis. For example, element A in context 1 and element B in context 2 cannot interact via z-index. This means that element A, as part of the overlay context that is at the very bottom of the overall overlay context, can never block element B of another context that is above the level, even with a very large z-index value.
But worse. The html element creates a root context overlay. Then, each non-static-positioned element with the z-index property not equal to auto also creates its own overlay context. Nothing new. But this is where everything starts to collapse: some non-context related css properties also create new contexts. For example, the opacity property.
That's right, the opacity property creates a new overlay context. The same is done by the transform and perspective properties. Although it makes no sense, does it? For example, if you have any element with opacity less than 1 or with any transformation, you could potentially have a problem.
Unfortunately, every problem with a z-index has its own context (not a pun) making impossible a universal solution.
Let's summarize the above:
- Before using z-index, be sure to set the position property not equal to static
- Do not use more than 5 digits for the value of z-index, it is absolutely meaningless; in most cases, a z-index value of around 10 will be more than enough
- Make sure that the element you want to overlap is in the same context overlay.
- If you still have something that does not work as it should, make sure that there are no transformations and opacity above the parent elements.
In the subject, I also recommend reading What is the One Told You About Z-index from Philip Walton and the official css specification .
Fighting the indentation collapse
As it seems to me - this is one of the css glitches, which steals the greatest amount of time to figure out what the matter is. We can say that it looks something like a bug with z-index. Be that as it may, the collapse of indents is when the upper and lower indents of two elements collapse into one (the largest of the two).
Fortunately, as a rule, this behavior is expected. Perhaps that is why it works this way (as stated in the css specification). However, sometimes you do not want the vertical indents to collapse. To understand how to avoid this, we will first see why this happens. Indent collapse can occur in three different cases.
Neighboring Items
When two adjacent elements have vertical indents - they collapse to the largest of them. There are several ways to prevent a collapse:
- clear: left; float: left; (right the same works)
- display: inline-block;
The example on jsFiddle illustrates the work of fixes.
Parent and first / last child
Usually, the top margin of the parent and child elements collapse to the largest. Similarly, it works for the last child and bottom indents. To solve this problem, there are also several ways. Most of which consist in adding one of the following properties to the parent element:
- overflow: hidden (or any other, but not visible)
- padding: 1px (or another value greater than 0)
- border: 1px solid transparent (or any other border)
- float: left (right the same works)
The example on jsFiddle illustrates the work of fixes.
Empty blocks
When an empty block has no boundaries, paddings, heights, its upper and lower indents collapse into one. Anyway, using empty blocks is a bad practice, so this is not common.
Conclusion
Unfortunately, only the tip of the iceberg of bugs and hacks css is described here. But these are really those that occur more often than others, but there are still many things such as browser incompatibility, vendor prefixes, the specificity of selectors, cascades and inheritance, and much more.
I would also recommend to read the following articles and sites:
- What is One Told You About Z-index by Philip Walton and its Habré , thanks to SelenIT2 for the tip
- By Roger Johansson's
- Official CSS Specification
- Micro clear-fix hack by Nicolas Gallagher
- Displaying inline-block by Robert Nyman
- Browserhacks by Tim Pietrusky and me
I hope the article has helped to understand some things that can save you from future problems.
Source: https://habr.com/ru/post/189252/
All Articles