mix-blend-mode wirkt zunächst wie eine reine Fleißaufgabe aus der Bildbearbeitung: ein Duotone-Effekt, ein Foto, das mit der Hintergrundfarbe verschmilzt, eine Überschrift, die durch das Bild darunter hindurchschimmert. Anders als in Photoshop oder Figma passiert das im Browser aber live: Jedes Element mit diesem Wert muss beim Rendering mit seinem jeweiligen Backdrop verrechnet werden, nicht nur einmal beim Speichern der Datei. Genau das macht mix-blend-mode zu einer der am meisten unterschätzten CSS-Eigenschaften: Sie sieht aus wie Gestaltung, verhält sich aber wie eine Rechenoperation.
mix-blend-mode legt fest, wie ein Element mit allem verschmilzt, was im selben Stacking Context dahinter liegt, nicht nur mit der eigenen Hintergrundfarbe. Dafür ist background-blend-mode zuständig, das mehrere Hintergrundebenen eines einzelnen Elements mischt.
.headline {
mix-blend-mode: difference;
}
Das Beispiel oben zeigt denselben Kreis vor demselben Hintergrund, nur mit wechselndem Blend-Modus, ein Umschalten zwischen den Werten macht den Unterschied schneller greifbar als jede Beschreibung.
Die Spezifikation kennt sechzehn Standardmodi: normal, multiply, screen, overlay, darken, lighten, color-dodge, color-burn, hard-light, soft-light, difference, exclusion, hue, saturation, color, luminosity. Level 2 der Compositing-Spezifikation ergänzt einen weiteren Wert, plus-lighter, der vor allem für Crossfades interessant ist.
Neben normal, das keine eigentliche Mischung vornimmt, arbeiten elf Modi trennbar: Jeder Farbkanal, Rot, Grün, Blau, wird für sich verrechnet. multiply etwa multipliziert die Kanäle einzeln und liefert immer ein dunkleres Ergebnis. Vier Modi arbeiten dagegen nicht trennbar: hue, saturation, color und luminosity betrachten Farbton, Sättigung und Luminosität gemeinsam, über eigene Funktionen der Spezifikation, nicht identisch mit dem L aus hsl(). Genau darin liegt ihr praktischer Wert: color übernimmt Farbton und Sättigung der Quelle und die Luminosität des Backdrops, die Grundlage für Colorize- und Tönungseffekte.
Ohne Gegenmaßnahme blendet ein Element mit allem, was im gleichen Stacking Context dahinter liegt, allerdings nur dort, wo sich die gerenderten Flächen tatsächlich überlappen. Ein Duotone-Overlay über einem Foto kann trotzdem unbeabsichtigt mit der Sektion darunter verschmelzen, sobald beide sichtbar überlappen und denselben Stacking Context teilen.
isolation: isolate auf einem umschließenden Element erzwingt einen neuen, eigenen Stacking Context und begrenzt die Blendung auf das, was innerhalb dieses Wrappers liegt:
.duotone {
isolation: isolate;
position: relative;
}
.duotone img {
filter: grayscale(1);
}
.duotone::before {
content: "";
position: absolute;
inset: 0;
background: var(--brand);
mix-blend-mode: color;
}
Das Muster taucht in nahezu jedem Duotone-Snippet auf, das im Netz kursiert, wird aber selten erklärt. Fehlt isolation: isolate, fällt der Fehler oft erst auf, wenn ein Redesign eine neue Sektion einfügt und plötzlich Farben ineinanderlaufen, die vorher getrennt waren.
Genau hier liegt der Punkt, den viele Einführungen zu mix-blend-mode auslassen: Der Effekt ist eine CSS-Eigenschaft, bei der man selbst auf gut ausgestatteten Rechnern einen Moment auf die fertige Anzeige warten kann.
Das liegt an einem Unterschied, der tiefer sitzt als reine Rechenleistung. background: blue beschreibt einen Zustand. mix-blend-mode: color beschreibt dagegen eine Beziehung zwischen zwei bereits gerenderten Dingen, der Quelle und ihrem Backdrop. Genau deshalb braucht die Eigenschaft überhaupt einen Hintergrund, um zu wirken, genau deshalb spielt Isolation eine Rolle, und genau deshalb dauert das Rendering länger.
Der Grund liegt nicht in einer festen Rollenverteilung zwischen CPU und GPU. Moderne Rendering-Pipelines wie Firefox’ WebRender geben ihre Befehle ohnehin an die GPU weiter, ein einfaches „Transform und Opacity laufen auf der GPU, mix-blend-mode auf der CPU" trifft die heutige Wirklichkeit nicht mehr zuverlässig. Der eigentliche Unterschied liegt in der Art der Berechnung: transform kann unter günstigen Bedingungen eine bereits fertig gerenderte Fläche einfach verschieben, ohne sie neu zu berechnen. Ein Blend-Modus dagegen muss die Pixel des Elements mit den Pixeln seines Backdrops, also allem, was bereits dahinter gerendert wurde, gemeinsam verrechnen. Quelle und Hintergrund lassen sich dabei nicht unabhängig behandeln, das Ergebnis hängt von beiden ab. Genau diese Abhängigkeit kann zusätzliche Render-Passes und Zwischenflächen erfordern, die eine einfache Verschiebung oder Transparenzänderung nicht benötigt.
Das erklärt auch, weshalb ein neuerer, leistungsstarker Mac das Problem nicht automatisch löst: Er rechnet die zusätzlichen Schritte schneller, ändert aber nichts daran, dass die Anzeige trotzdem einen Moment auf sich warten lässt, sobald Quelle und Backdrop gemeinsam verrechnet werden müssen. Das kann sich schon beim ersten Aufbau der Seitebemerkbar machen, vor allem bei großflächigen oder bildreichen Bereichen: Bis Quelle und Backdrop zusammengerechnet sind, steht die Anzeige noch nicht vollständig. In der Praxis kommt das zusätzlich zum Tragen, wenn ein Element mit mix-blend-mode gescrollt oder animiert wird oder sich sein Backdrop laufend verändert, dann wiederholt sich dieses Warten mit jeder Änderung, Frame für Frame. Dokumentierte Fälle reichen von ruckelndem Scrollen bildlastiger Seiten bis zu Lüftern, die unter Last hochdrehen, während dieselbe Seite ohne den Blend-Modus flüssig läuft.
Drei Vorsichtsmaßnahmen helfen in der Praxis: den Effekt kleinflächig einsetzen statt auf ganzen Hero-Bereichen, ihn nicht mit Scroll-gebundenen Animationen oder Video kombinieren, wenn es sich vermeiden lässt, und die tatsächliche Wirkung im Performance-Panel der DevTools messen, mit Rendering-Stats, Paint Flashing und Layer Borders, statt sie von einer Liste vermeintlich schneller Eigenschaften abzuleiten. Wie lange eine solche Berechnung tatsächlich dauert, hängt von Engine, Plattform, Fläche und dem übrigen Rendering-Kontext ab, nicht von einer pauschalen Regel.
Für die etablierten Modi ist Browserkompatibilität heute kein ernstes Thema mehr: MDN führt mix-blend-mode inzwischen als breit verfügbar. plus-lighter ist jünger als die klassischen Blend-Modi und lohnt vor allem dort einen gesonderten Blick, wo ältere Browser noch zum Projektumfang gehören.
Interessanter als reine Verfügbarkeit sind Rendering-Bugs in bestimmten Kombinationen, die auch in vergleichsweise jungen Browserversionen noch dokumentiert sind: mit position: fixed auf großen Flächen, beim Zoomen, bei Layer-Tiling, mit SVG oder in Kombination mit Animationen. WebKit hat mehrfach dokumentiert, dass Blend-Modi in Safari unter solchen Bedingungen aussetzen können. Ein Duotone-Effekt, der in Chrome exakt sitzt, verdient deshalb vor dem Launch einen Blick ins echte Safari, nicht nur in die Device-Emulation der Chrome-DevTools.
CSS-Eigenschaft, die festlegt, wie ein Element mit dem Inhalt verschmilzt, der im selben Stacking Context dahinter liegt.
Der Bereich, innerhalb dessen der Browser die Reihenfolge und Überlagerung von Elementen entlang der Z-Achse verwaltet. isolation: isolate erzwingt einen neuen, eigenen.
Der bereits gerenderte Inhalt hinter einem Element, mit dem es sich beim Blending mischt.
Der Schritt, in dem der Browser mehrere gerenderte Ebenen zum finalen Bild zusammenfügt.
Unterscheidung danach, ob ein Blend-Modus (neben normal ) jeden Farbkanal einzeln (trennbar) oder Farbton, Sättigung und Luminosität gemeinsam (nicht-trennbar) verrechnet.