Solving Background Overflow With Inherited Border Radii

One of the interesting (but annoying) things about CSS is that the background of child elements can extend beyond the parent element’s border radius. Here is an example of a card with an inner element. If the inner element is given a background, it can extend beyond the edge of the card.

The easiest way to solve this problem is to add overflow: hidden to the map element. I’m sure this is the solution most of us reach for when something like this happens.

However, this introduces a new problem: content outside the map element is cut off. Therefore you cannot use negative margins position: absolute to move the child content out of the map.

There is a slightly more laborious but effective way to prevent a child’s background from disappearing from that of their parents border-radius. And this is to add the same thing border-radius to the child element.

The easiest way to do this is to allow the child to do it inherit those of the parents border-radius:

.child {
  border-radius: inherit;
}

If the border-radius If the shortcut is too much, you can still inherit the radius for each of the four corners on a case-by-case basis:

.child {
  border-top-left-radius: inherit;
  border-top-right-radius: inherit;
  border-bottom-left-radius: inherit;
  border-bottom-right-radius: inherit;
}

For those of you willing to use logical properties, here is the equivalent. (To make logical properties easier to understand, replace top and left with startAnd bottom And right with end.)

.child {
  border-start-start-radius: inherit;
  border-top-end-radius: inherit;
  border-end-start-radius: inherit;
  border-end-end-radius: inherit;
}

Can’t we just apply a background to the card?

If you have one background directly on .card that contains the border-radiusachieve the same effect. So why not?

Well, sometimes that doesn’t work. A situation is when you have one .card this is divided into two parts and only one part is colored.

So why should we do this?

Peace of mind is probably the best reason. At least you know you won’t cause problems later with the radius manipulation solution.

This pattern will be especially helpful if CSS anchor positioning receives full support. I expect that popover positioning will soon become the norm in about a year or two.

However, with popovers, my preference is to move the popover content from the document flow to the Element as a direct descendant. This is how I prevent it overflow: hidden that I don’t clip any of my popovers when I use anchor positioning.