Ist das das erwartete Verhalten?
Ja, so verrückt es auch klingt, es ist es tatsächlich. Hier ist der Grund:
Die Standardeinstellung overflowfür <div>Elemente (und die meisten anderen Dinge) ist visible, und die Spezifikation sagt Folgendes aus overflow: visible:
sichtbar
Dieser Wert gibt an, dass der Inhalt nicht abgeschnitten ist, dh außerhalb des Blockfelds gerendert werden kann.
In §5.3 Eckausschnitt im Modul Hintergründe und Rahmen heißt es wiederum:
Die Hintergründe einer Box, aber nicht das Rahmenbild, werden auf die entsprechende Kurve zugeschnitten (wie durch 'Hintergrund-Clip' bestimmt). Andere Effekte, die am Rand oder an der Auffüllkante befestigt werden (z. B. "Überlauf" außer "sichtbar"), müssen ebenfalls an der Kurve befestigt werden. Der Inhalt der ersetzten Elemente wird immer auf die Inhaltskantenkurve zugeschnitten. Außerdem akzeptiert der Bereich außerhalb der Kurve der Randkante keine Mausereignisse für das Element.
Der Satz , dass ich ausdrücklich erwähnt betonte , dass der overflowWert der Box etwas anderes sein muss als visible(das bedeutet auto, hidden, scrollund andere) , um für die Ecken ihrer Kinder zu befestigen.
Wenn für das Feld ein sichtbarer Überlauf definiert ist, der, wie gesagt, die Standardeinstellung für die meisten visuellen Elemente ist, sollte der Inhalt überhaupt nicht abgeschnitten werden. Und deshalb gehen die quadratischen Ecken von .bufferüber die abgerundeten Ecken von .progressbar.
Folglich ist der einfachste Weg, um .bufferinnerhalb .progressbarder abgerundeten Ecken zu schneiden, das Hinzufügen eines overflow: hiddenStils .progressbar, wie in dieser aktualisierten Geige gezeigt .