Pseudo-Elemente für Inputs: ::-webkit- und ::-moz- gezielt einsetzen

1. Warum Browser-Präfixe bei Formularelementen noch immer notwendig sind

Die meisten CSS-Präfixe wie -webkit-transform oder -moz-user-select sind heute Geschichte, weil die zugrunde liegenden Eigenschaften längst standardisiert wurden. Bei internen Teilen von Formularelementen sieht die Lage anders aus: Der Daumen eines Range-Sliders, der Button eines Datei-Uploads oder die Spin-Pfeile eines Zahlenfelds sind nicht Teil des offenen DOM, sondern Teil der User-Agent-Shadow-Root, die jeder Browser individuell implementiert. Es gibt bis heute keinen standardisierten, präfixfreien Selektor für diese Teile, deshalb bleiben herstellerspezifische Pseudo-Elemente in diesem Bereich unverzichtbar.

Das bedeutet konkret: Wer den Daumen eines input type="range" gestalten will, schreibt in der Praxis zwei fast identische Regelblöcke, einen für ::-webkit-slider-thumb und einen für ::-moz-range-thumb, weil Chrome, Safari und Edge die WebKit-Engine beziehungsweise Blink nutzen, während Firefox eigene Pseudo-Elemente mit dem -moz--Präfix verwendet. Diese Dopplung wirkt auf den ersten Blick unelegant, ist aber der einzig funktionierende Weg, weil ein Selektor, den ein Browser nicht kennt, die komplette Regel ungültig macht, wenn er in derselben Selektorliste steht.

2. Überblick: Welche Pseudo-Elemente existieren wo

Bevor man einzelne Formularelemente gestaltet, lohnt sich ein Überblick, welche Pseudo-Elemente in welcher Browser-Familie existieren. WebKit und Blink, also Safari, Chrome, Edge und die meisten Chromium-basierten Browser, teilen sich weitgehend dieselben ::-webkit-*-Pseudo-Elemente, weil Blink historisch aus WebKit hervorgegangen ist. Firefox nutzt ein eigenes Set mit ::-moz-*-Präfix, das strukturell ähnlich, aber nicht identisch benannt ist.

Die wichtigsten Pseudo-Elemente für Formulare sind ::-webkit-slider-thumb und ::-moz-range-thumb für Range-Slider, ::-webkit-slider-runnable-track und ::-moz-range-track für die Spur, ::-webkit-file-upload-button für Datei-Auswahl-Buttons, ::-webkit-search-cancel-button für das Kreuz in Suchfeldern, sowie ::-webkit-inner-spin-button für die Pfeile in input type="number". Firefox rendert einige dieser Elemente grundlegend anders oder verzichtet ganz darauf, was bei der Planung berücksichtigt werden muss.

/* Must be split into separate selector lists, one invalid selector
   invalidates the entire rule in the same list */
input[type="range"]::-webkit-slider-thumb {
  -webkit-appearance: none;
  appearance: none;
}

input[type="range"]::-moz-range-thumb {
  appearance: none;
}

/* WRONG: combining vendor pseudo-elements in one selector list
   invalidates the whole rule in most browsers */
input[type="range"]::-webkit-slider-thumb,
input[type="range"]::-moz-range-thumb {
  background: red; /* never applied anywhere */
}

3. Range-Slider-Thumb mit webkit-slider-thumb und moz-range-thumb

Der Daumen eines Range-Sliders ist das Element, das am häufigsten individuell gestaltet wird, etwa mit einem Schatten, einer eigenen Form oder einem Hover-Effekt. Um den nativen Daumen komplett zu ersetzen, wird zunächst appearance: none auf das Pseudo-Element selbst gesetzt, danach lassen sich Breite, Höhe, Radius, Hintergrund und Übergang frei definieren, exakt wie bei jedem anderen Block-Element. Wichtig ist, dass -webkit-appearance: none zusätzlich zur standardisierten appearance: none gesetzt wird, weil Safari die Standard-Eigenschaft in manchen Versionen erst verspätet unterstützt hat.

Ein häufiger Stolperstein: Die Größe des Range-Elements selbst muss ebenfalls über appearance: none auf das Basiselement zurückgesetzt werden, sonst überlagert der native Rahmen die eigene Gestaltung des Daumens. Zusätzlich verhält sich der vertikale Versatz des Daumens bei WebKit anders als bei Firefox, weil WebKit den Daumen über margin-top relativ zur Track-Höhe positioniert, während Firefox das automatisch zentriert. Diese Detailunterschiede sind der Hauptgrund, warum ein Range-Slider ohne Tests in mehreren echten Browsern selten auf Anhieb konsistent aussieht.

input[type="range"] {
  -webkit-appearance: none;
  appearance: none;
  width: 100%;
  height: 6px;
  background: #e5e7eb;
  border-radius: 999px;
}

/* Chrome, Safari, Edge (Blink/WebKit) */
input[type="range"]::-webkit-slider-thumb {
  -webkit-appearance: none;
  appearance: none;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  background: #7c3aed;
  box-shadow: 0 2px 6px rgba(124, 58, 237, 0.4);
  cursor: pointer;
  /* WebKit positions the thumb relative to the track height manually */
  margin-top: -7px;
}

/* Firefox */
input[type="range"]::-moz-range-thumb {
  width: 20px;
  height: 20px;
  border: none;
  border-radius: 50%;
  background: #7c3aed;
  box-shadow: 0 2px 6px rgba(124, 58, 237, 0.4);
  cursor: pointer;
}

4. Placeholder-Styling mit ::placeholder und Fallbacks

Das Pseudo-Element ::placeholder ist inzwischen standardisiert und benötigt in aktuellen Browsern keinen Präfix mehr, dennoch ist es historisch eng mit der Präfix-Thematik verwandt, weil ältere Firefox-Versionen ::-moz-placeholder mit einem einzelnen Doppelpunkt und abweichender Deckkraft verwendeten. In aktuellen Projekten reicht ::placeholder allein aus, aber wer Legacy-Support für Firefox unter Version 51 benötigt, ergänzt weiterhin ::-moz-placeholder als separate Regel.

Ein Detail, das Entwickler regelmäßig überrascht: Firefox hat lange eine reduzierte Deckkraft von 0.54 auf Placeholder-Text angewendet, was zu inkonsistenter Farbwahrnehmung im Vergleich zu Chrome führte, wo die volle definierte Farbe angezeigt wurde. Die Lösung ist, opacity: 1 explizit in der ::placeholder-Regel zu setzen, unabhängig vom Browser, um sicherzustellen, dass die gewählte Farbe überall identisch dargestellt wird.

/* Standardized, no prefix needed in current browsers */
input::placeholder,
textarea::placeholder {
  color: #9ca3af;
  opacity: 1; /* Firefox historically applied reduced opacity by default */
}

/* Legacy fallback for very old Firefox versions (single colon syntax) */
input:-moz-placeholder {
  color: #9ca3af;
  opacity: 1;
}

5. Datei-Upload-Button mit webkit-file-upload-button

Der Button innerhalb eines input type="file", der in Chrome und Safari standardmäßig "Datei auswählen" anzeigt, lässt sich ausschließlich über ::-webkit-file-upload-button individuell gestalten, in WebKit- und Blink-basierten Browsern. Firefox rendert diesen Button intern anders und bietet kein direktes Äquivalent-Pseudo-Element, weshalb Datei-Upload-Felder in Firefox meist über ein verstecktes natives Input plus ein eigenes Label-Element gestaltet werden, statt über direktes Pseudo-Element-Styling.

Für ein konsistentes Erscheinungsbild über alle Browser hinweg empfiehlt sich generell die Label-Technik: Das native input type="file" wird visuell versteckt, aber zugänglich gehalten, mit opacity: 0 und exakter Positionierung über dem sichtbaren Label, das als Button gestaltet ist. Diese Technik funktioniert unabhängig vom Browser, weil sie kein Pseudo-Element-Styling voraussetzt, während ::-webkit-file-upload-button in Projekten sinnvoll bleibt, die ausschließlich Chromium-Browser unterstützen müssen, etwa in internen Admin-Tools.

/* Direct pseudo-element styling, Chromium/WebKit only */
input[type="file"]::-webkit-file-upload-button {
  background: #7c3aed;
  color: white;
  border: none;
  border-radius: 0.5rem;
  padding: 0.5rem 1rem;
  font-weight: 600;
  cursor: pointer;
  margin-right: 1rem;
}

input[type="file"]::-webkit-file-upload-button:hover {
  background: #6d28d9;
}

/* Cross-browser fallback: visually hidden native input plus styled label */
.file-input-wrapper input[type="file"] {
  position: absolute;
  opacity: 0;
  width: 100%;
  height: 100%;
  cursor: pointer;
}

.file-input-wrapper label {
  display: inline-block;
  background: #7c3aed;
  color: white;
  border-radius: 0.5rem;
  padding: 0.5rem 1rem;
  font-weight: 600;
}

6. Search-Cancel-Button und Spin-Buttons bei number-Inputs

Zwei weitere Formular-Details, die ausschließlich über herstellerspezifische Pseudo-Elemente steuerbar sind: das kleine Kreuz-Icon zum Leeren eines input type="search", das über ::-webkit-search-cancel-button entfernt oder umgestaltet wird, und die auf und ab Pfeile eines input type="number", die über ::-webkit-inner-spin-button beziehungsweise ::-webkit-outer-spin-button angesprochen werden. In vielen Designsystemen werden diese Spin-Buttons komplett entfernt, weil eigene Increment- beziehungsweise Decrement-Buttons per JavaScript oder Alpine.js gebaut werden, die sich exakter ins Layout einfügen lassen.

Firefox behandelt beide Fälle anders: Der Search-Cancel-Button existiert dort schlicht nicht als separates Element, und die Spin-Buttons eines Number-Inputs werden über die Standard-Eigenschaft appearance: textfield auf dem Input selbst entfernt, nicht über ein Pseudo-Element. Ein robustes, browserübergreifendes Muster kombiniert deshalb beide Ansätze: das WebKit-Pseudo-Element für Chrome und Safari, dazu die Standard-Eigenschaft appearance: textfield, die in Firefox unmittelbar wirkt und in WebKit-Browsern als redundante, aber unschädliche Ergänzung fungiert.

/* Remove the search cancel cross (WebKit/Blink only) */
input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: none;
  appearance: none;
}

/* Remove spin buttons on number inputs, cross-browser approach */
input[type="number"] {
  -moz-appearance: textfield; /* Firefox: removes spinners via standard property */
  appearance: textfield;
}

input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  appearance: none;
  margin: 0;
}

7. Autofill-Hintergrund mit webkit-autofill überschreiben

Eines der hartnäckigsten Styling-Probleme bei Formularen ist der gelbliche Hintergrund, den Chrome und Safari automatisch auf ausgefüllte Felder anwenden, sobald der Browser Zugangsdaten oder Adressdaten automatisch einträgt. Dieser Hintergrund lässt sich nicht mit background-color überschreiben, weil der Browser die Hintergrundfarbe des ::-webkit-autofill-Zustands mit höherer Priorität rendert als reguläre CSS-Regeln. Die etablierte Lösung ist ein Trick über box-shadow: Ein großer, unsichtbarer inset-Schatten in der gewünschten Hintergrundfarbe überlagert den Autofill-Hintergrund vollständig, ohne dass eine echte Schattenwirkung sichtbar wird.

Zusätzlich sollte -webkit-text-fill-color gesetzt werden, weil Chrome auch die Textfarbe in ausgefüllten Feldern manchmal überschreibt und die reguläre color-Eigenschaft dabei ignoriert. Eine sehr lange transition-delay auf background-color ist ein weiterer verbreiteter Trick, der den automatischen Farbwechsel praktisch unendlich verzögert, sodass die eigene Hintergrundfarbe visuell nie überschrieben wird. Firefox kennt dieses Problem in der Form nicht, weil es das Autofill nicht mit einer eigenen Hintergrundfarbe kennzeichnet.

/* The classic box-shadow trick to override the yellow autofill background */
input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus {
  box-shadow: 0 0 0 1000px white inset;
  -webkit-text-fill-color: #1f2937;
  /* Delay the color transition so the browser's own background never shows */
  transition: background-color 600000s 0s, color 600000s 0s;
}

/* Dark mode variant: match the surrounding form background */
@media (prefers-color-scheme: dark) {
  input:-webkit-autofill {
    box-shadow: 0 0 0 1000px #1e293b inset;
    -webkit-text-fill-color: #f1f5f9;
  }
}

8. Wartungsstrategie: Mixins und Custom Properties statt Duplizierung

Weil herstellerspezifische Pseudo-Elemente fast immer paarweise auftreten, webkit plus moz, lohnt sich eine strukturierte Wartungsstrategie, die Duplizierung reduziert, ohne die Notwendigkeit getrennter Selektorlisten zu umgehen. In Sass oder Less lässt sich ein Mixin definieren, das beide Regelblöcke aus einem gemeinsamen Satz an Deklarationen generiert, sodass Änderungen nur an einer Stelle im Quellcode vorgenommen werden müssen. In reinem CSS ohne Preprocessor übernehmen Custom Properties diese Rolle: Ein gemeinsamer Satz von Variablen für Farbe, Größe und Schatten wird in beiden Pseudo-Element-Regeln referenziert.

Diese Strategie zahlt sich besonders bei Range-Slidern und Datei-Upload-Buttons aus, weil hier typischerweise fünf bis acht Eigenschaften in beiden Präfix-Varianten identisch sind und nur ein oder zwei Eigenschaften browserspezifisch abweichen, etwa der vertikale Versatz des Range-Thumbs. Wer ein Design-System pflegt, sollte diese Pseudo-Element-Regeln zentral in einer einzigen Formular-Basis-Datei bündeln, damit spätere Anpassungen der Markenfarbe nicht an mehreren Stellen im Projekt manuell nachgezogen werden müssen.

/* Shared design tokens referenced by both vendor pseudo-elements */
:root {
  --thumb-size: 20px;
  --thumb-color: #7c3aed;
  --thumb-shadow: 0 2px 6px rgba(124, 58, 237, 0.4);
}

input[type="range"]::-webkit-slider-thumb {
  -webkit-appearance: none;
  width: var(--thumb-size);
  height: var(--thumb-size);
  border-radius: 50%;
  background: var(--thumb-color);
  box-shadow: var(--thumb-shadow);
  margin-top: calc((var(--thumb-size) - 6px) / -2);
}

input[type="range"]::-moz-range-thumb {
  width: var(--thumb-size);
  height: var(--thumb-size);
  border: none;
  border-radius: 50%;
  background: var(--thumb-color);
  box-shadow: var(--thumb-shadow);
}

9. Pseudo-Elemente-Unterstützung im Browser-Vergleich

Die folgende Übersicht zeigt, welche der wichtigsten herstellerspezifischen Pseudo-Elemente in welcher Browser-Familie verfügbar sind, und ob eine Alternative über Standard-Eigenschaften existiert.

Die Tabelle zeigt ein klares Muster: Nur der Placeholder ist vollständig standardisiert, alle anderen Details erfordern entweder ein Pseudo-Element pro Browser-Familie oder eine komplett andere Herangehensweise, etwa die Label-Overlay-Technik beim Datei-Upload. Wer ein Formular-System für den produktiven Einsatz baut, sollte diese Tabelle als Checkliste für die Browsertests verwenden, bevor ein Release freigegeben wird.

10. Zusammenfassung

Herstellerspezifische Pseudo-Elemente bleiben notwendig, weil Teile von Formularelementen wie der Range-Thumb, der Datei-Upload-Button und der Autofill-Hintergrund bis heute nicht vollständig standardisiert sind. Die Regel dabei: getrennte Selektorlisten für ::-webkit-* und ::-moz-*, weil ein unbekannter Selektor die gesamte Regel ungültig macht, wenn beide in derselben Liste stehen. Placeholder-Styling ist mittlerweile standardisiert und benötigt keinen Präfix mehr, während Range-Thumb, Upload-Button und Autofill weiterhin präfixgebundene Lösungen erfordern.

Für nachhaltige Wartbarkeit lohnt sich ein zentraler Satz an Custom Properties oder ein Sass-Mixin, das beide Präfix-Varianten aus einer gemeinsamen Quelle generiert. Der box-shadow-inset-Trick gegen das Autofill-Gelb und die Kombination aus appearance: textfield und ::-webkit-inner-spin-button gegen Zahlenfeld-Pfeile gehören zu den am häufigsten benötigten Patterns in produktiven Formularen.

11. FAQ: Pseudo-Elemente für Inputs