Es ist ein Detail, das auffällt. Kein Bug, aber eine Unschönheit. Was folgt, ist kein Tutorial mit einer sauberen Lösung am Ende. Es ist eine Dokumentation dessen, wie weit man mit reinem CSS kommt – und wo die Grenze liegt.

Warum passiert es?

Der Grund liegt im inline formatting context. Ein Pseudo-Element – ob :before oder :after – ist für den Browser eine eigenständige inline box. Es verhält sich wie ein separates Element direkt vor oder nach dem Inhalt, nicht als Teil davon.

Das öffnende Anführungszeichen steht vor dem ersten Wort und bricht damit praktisch nie allein um. Das schliessende steht nach dem letzten Wort – und genau da liegt das Problem. Wenn der Text die letzte Zeile fast vollständig füllt, schiebt der Browser die schliessende inline box auf eine neue Zeile. Typografisch falsch, technisch korrekt.

Case 1 – HTML

In diesem Fall ist das Markup ein Kompromiss. Die Struktur orientiert sich am MDN-Beispiel für blockquote – Quellenangabe ausserhalb des blockquote – aber die Umsetzung weicht etwas davon ab. Es ist das Machbare in diesem Fall (und CMS) gewesen, nicht das Ideale.

display: inline-table auf dem blockquote ist eine mögliche Lösung. Sie macht das Element zu einem inline-level block container: Das :after-Pseudo-Element ist damit nicht mehr eine freie inline box, sondern bleibt am letzten Wort gebunden – unabhängig von dynamischen Schriftgrössen oder responsiven Layouts.

Die folgende Lösung läuft seit etwa einem Jahr (seit Mitte 2025) auf einer produktiven Website stabil. Fast alle Auflösungen sind abgedeckt, nur in absoluten Extremfällen – grosse Schrift, besonders bei dynamischen Werten mit calc() oder vw-Einheiten und sehr schmalen Containern – zeigen sich noch Ausreisser.

<div class="quote-wrapper">
    <blockquote>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.</p>
    </blockquote>
    <p class="quote-by-wrapper"><span>— </span><span>Stet clita</span></p>
</div>
blockquote {
    quotes: "«" "»";
    display: inline-table; // this is where the magic happens

    &:before {
        content: open-quote;
    }

    &:after {
        content: close-quote;
    }

    p {
        display: inline;
    }
}

Case 2 – WordPress Pullquote

Beim WordPress Pullquote-Block (Zitatkasten) ist das Markup vorgegeben – es kann nicht «einfach so» verändert werden, und auch dieses Markup ist nicht frei von Kompromissen. Der direkte Griff auf das blockquote entfällt damit. Der beste Angriffspunkt via CSS ist .wp-block-pullquote p.

Bevor es zum Code geht, eine Randbemerkung zum quotes-Property: Den Abstand zwischen Anführungszeichen und Text über einen Space im String zu lösen – "« " statt "«" – ist ein Hack. Sauber sind Margins auf den Pseudo-Elementen.

Das Verhalten ist identisch zu Case 1: in den meisten Fällen einwandfrei, in absoluten Extremfällen dieselben Ausreisser. Getestet im Juni 2026 in Safari, Chrome, Firefox und Edge.

<blockquote>
    <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.</p>
    <cite>– <a href="#">Marcel Best</a></cite>
</blockquote>
.wp-block-pullquote p {
    quotes: "«" "»";
    display: inline-block;

    &:before {
        content: open-quote;
        display: inline-block;
        margin-right: 0.5rem;
    }

    &:after {
        content: close-quote;
        display: inline-block;
        margin-left: 0.5rem;
    }
}

Was nicht funktioniert – und warum

display: inline-flex auf dem p liegt als Gedanke nahe – Flexbox gibt präzise Kontrolle über die Ausrichtung von Elementen, also müsste sich das schliessende Anführungszeichen doch ans letzte Wort binden lassen. Leider funktioniert das nicht.

In einem Flex-Container werden Pseudo-Elemente als eigenständige Flex-Items behandelt. align-self: flex-end auf :after verschiebt das Anführungszeichen ans Ende des Containers – aber nicht ans letzte Wort des Textes. Das Ergebnis ist dasselbe Problem, nur anders verpackt.

Flexbox löst hier nichts, weil es das falsche Werkzeug für dieses Problem ist.

Fazit

Typografische Details wie dieses fallen selten auf – bis sie auffallen. CSS bietet Möglichkeiten, um das Problem in den meisten Fällen zu lösen, aber es bietet keine Garantie für jeden Extremfall. display: inline-table scheint eine Option zu sein, wenn das Markup – wie in Case 1 – geschrieben ist. Beim WordPress Pullquote und auch im Normalfall ist display: inline-block mit sauberen Margins der pragmatische Weg.

display: inline-block erzeugt einen block formatting context, der sich als inline verhält – semantisch die korrektere Wahl für ein p oder blockquote. display: inline-table hingegen zwingt einem Element einen Tabellenformatierungskontext auf, was technisch funktioniert, aber semantisch nicht passt. Nachzulesen in der MDN-Dokumentation zum display-Property.

Wer das Problem kennt, weiss wo er ansetzen muss – und wann er aufhören kann zu suchen. Es gibt einfach Situationen, in denen man mit einem Kompromiss leben muss.