Is this the expected behavior?
Yes, as crazy as it sounds, it actually is. Here’s why:
The default overflow for <div> elements (and most other things) is visible, and the spec says this about overflow: visible:
visible
This value indicates that content is not clipped, i.e., it may be rendered outside the block box.
In turn, §5.3 Corner clipping in the Backgrounds and Borders module says:
A box’s backgrounds, but not its border-image, are clipped to the appropriate curve (as determined by ‘background-clip’). Other effects that clip to the border or padding edge (such as ‘overflow’ other than ‘visible’) also must clip to the curve. The content of replaced elements is always trimmed to the content edge curve. Also, the area outside the curve of the border edge does not accept mouse events on behalf of the element.
The sentence that I’ve emphasized specifically mentions that the overflow value of the box must be something other than visible (that means auto, hidden, scroll and others) in order for the corners to clip its children.
If the box is defined to have visible overflow, which like I said is the default for most visual elements, then the content is not supposed to be clipped at all. And that’s why the square corners of .buffer go over the rounded corners of .progressbar.
Consequently, the simplest way to get .buffer to clip within .progressbar‘s rounded corners is to add an overflow: hidden style to .progressbar, as shown in this updated fiddle.