CSS issues. Part 2

Original author: Hugo Giraudel
  • Transfer
Continued translation of the article “CSS Issues. Part 1 " .

When to use width / height equal to 100%?


Height: 100%

Let's start with the simpler one. When to use height: 100% ? In fact, the question often sounds a little different: "How can I make my page fill the entire height of the screen?" Is it true?

To answer it, you need to understand that height: 100% is equal to the height of the parent element. This is not a magical “window height”. 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 that its height is equal to the height of the content. Of course, you can try adding height: 100% to the body, but that won't be enough either.

Why? And all the same, the parent of the body element is the html element, which also has the property height equal to auto and it also stretches to the size of the content. And now, if you add height: 100% to the html element, it will work.

Has it become clearer? The root html element is actually not the highest level on the page - it is “viewport”. For simplicity, we assume that this is a browser window. So, if you set height: 100% to the html element, then this is the same as saying - become the same height as the browser window.

Summarize the information in a small piece of code:

html, body, .container {
    height: 100%;
}

Done. If you are interested in delving into the topic of how viewport works, I highly recommend an article from PPK .

But what if the parent element has the min-height property set, not the height?

Recently, Roger Johansson described a problem with height: 100% that occurs when the parent element is not set to height but min-height is specified. I do not want to delve into what was said in the article, but I will go straight to the conclusions. You need to set height: 1px for the parent so that the child can occupy the entire height specified in min-height.

.parent {
    min-height: 300px;
    height: 1px; /* Required to make the child 100% of the min-height */
}
.child {
    height: 100%;
}

Example on jsFiddle .

In more detail, with this question, you can familiarize yourself with an article by Roger Johansson .

Width: 100%

Now let's deal with width: 100% . To begin with, a small clarification: setting the width: 100% property , we want our element to occupy 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 suitable 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 in the parent element. Because padding and border appeared, and that's why width should have been called content-width. Now, please look at an example demonstrating the above.

Example on jsFiddle .

Let's say that the width of the parent is 25em, and that of the child is 100% (of the width of the parent) and it also has padding equal to 1em (1em to the right and 1em to the left, at least 2em horizontally) and a border of 0.5em in size (0.5 em to the right and 0.5 em to the left, totally 1em horizontally ), which in the end gives us 25em (100%) + 2em + 1em = 28em.

There are 4 possible solutions to 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 problem with paddings and borders). But if we work with an inline-block element, then we will not be able to solve this problem so simply.

We can replace width: 100%on static size. In our case, 25 - (2 + 1) = 22em. Of course, 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 padding + border sizes. 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 properties of padding and border. 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 screw up with z-index.


All elements on the page are positioned in three planes: in addition to the vertical and horizontal axis, there is an additional Z axis (depth). At first, everything looks very simple - elements with a large z-index are higher than elements with a smaller z-index. Unfortunately, everything is much more complicated. I am sure that z-index is the most complex css property in its history. And I'm also sure that the problems associated with z-index are more common than others when working with css. I hope that we will enlighten possible solutions.

To start. The z-index property has no effect on static elements. To be able to move the 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 at 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 an overlay context.

In simple words, an overlay context is, in a way, a group based on one html element, in which all child elements get the same position in the context and the same z-index. Changes in the z-index of an element can cause it to overlap other elements, as you need. This is how elements are arranged in one overlay context (bottom to top):

  1. Background and borders of the context element
  2. Negative z-index child overlay contexts (smallest first)
  3. Un positioned items
  4. Positioned items with z-index set to auto or 0
  5. Positioned elements with a positive z-index (each next in order is higher than the previous one, if z-index is equal)

When the situation becomes unpleasant

So, we examined 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 simple.

The fact 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 at the very bottom of the overall overlay context, can never overlap element B of another context above the level, even with a very large z-index value.

But, even worse. The html element creates the root overlay context. Then, each non-statically positioned element with the z-index property not equal to auto also creates its own overlay context. Nothing new. But here is where everything begins to crumble: some properties that are not related to the css overlay context in any way also create new contexts. For example, the opacity property.



That's right, the opacity property creates a new overlay context. The transform and perspective properties do the same. Although this makes no sense, does it? For example, if you have any element with an opacity less than 1 or with any transformation, you could potentially have a problem.

Unfortunately, each problem with z-index has its own context (not a pun) making a universal solution impossible.

Let's summarize the above:

  • Before applying z-index, be sure to set the position property to non-static
  • Do not use more than 5 digits for the z-index value, this is completely pointless; in most cases, a z-index of around 10 will be more than enough
  • Make sure that the element you want to overlap is in the same overlay context.
  • If something is still not working as it should, make sure that there are no transformations and the opacity is higher for the parent elements.


On the topic, I also recommend reading What No One Told You About Z-index by Philip Walton and the official css specification .

Indenting Collapse


It seems to me - this is one of the css glitches that steals the most amount of time to figure out what’s the matter. We can say that it is somewhat similar to a bug with z-index. Be that as it may, collapse of the 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 like that (as indicated in the css spec). However, sometimes you do not want vertical margins to collapse. To understand how to avoid this, we will first see why this happens. Indentation collapse can occur in three different cases.

Nearby Items

When two adjacent elements have vertical indents, they collapse to the largest of them. There are several ways to prevent collapse:

  • clear: left; float: left; (right works the same)
  • display: inline-block;


The jsFiddle example illustrates how fixes work.

Parent and first / last child

Usually, the top indent of the parent and child elements collapse to the largest. It works similarly for the last child and the bottom indentation. To solve this problem, there are also several ways. Most of which are to add 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 works the same)


The jsFiddle example illustrates how fixes work.

Empty blocks

When an empty block has no borders, paddings, heights, its upper and lower indents collapse into one. One way or another, using empty blocks is bad practice, so this is not common.

Conclusion


Unfortunately, only the tip of the iceberg from css bugs and hacks is described here. But these are really those that are more common than others, but there are many more things such as: browser incompatibility, vendor prefixes, selector specificity, cascades and inheritance, and much more.

I would also recommend reading the following articles and sites:



I hope the article helped to understand some things that can save you from problems in the future.

Also popular now: