Ein rutschender Albtraum: Das Range Input verstehen

Sie haben vielleicht schon eine Vielzahl von Tutorials gesehen, wie man das Range-Input gestaltet. Während dies ein weiterer Artikel zu diesem Thema ist, geht es nicht darum, wie man ein bestimmtes visuelles Ergebnis erzielt. Stattdessen taucht er in Browser-Inkonsistenzen ein und beschreibt, was jeder einzelne Browser tut, um diesen Schieberegler auf dem Bildschirm anzuzeigen. Das Verständnis dessen ist wichtig, da es uns hilft, eine klare Vorstellung davon zu bekommen, ob wir unseren Schieberegler browserübergreifend konsistent aussehen und sich verhalten lassen können und welche Stile dafür notwendig sind.

Ein Blick ins Innere eines Range-Inputs

Bevor wir uns um etwas anderes kümmern, müssen wir sicherstellen, dass der Browser das DOM im Inneren des Range-Inputs anzeigt.

In Chrome rufen wir DevTools auf, gehen zu Einstellungen, Präferenzen, Elemente und stellen sicher, dass die Option Shadow DOM von Benutzeragenten anzeigen aktiviert ist.

In Firefox gehen wir zu about:config und stellen sicher, dass das Flag devtools.inspector.showAllAnonymousContent auf true gesetzt ist.

Lange Zeit war ich davon überzeugt, dass Edge keine Möglichkeit bietet, das Innere solcher Elemente anzuzeigen. Aber beim Herumspielen damit entdeckte ich, dass wo ein Wille und (und etwas dummes Glück) ist, ein Weg ist! Wir müssen DevTools aufrufen, dann das zu inspizierende Range-input auswählen, mit der rechten Maustaste darauf klicken, Element untersuchen auswählen und zack, das DOM-Explorer-Panel zeigt nun die Struktur unseres Schiebereglers!

Anscheinend ist das ein Bug. Aber es ist auch immens nützlich, also beschwere ich mich nicht.

Die innere Struktur

Von Anfang an sehen wir eine Quelle potenzieller Probleme: Wir haben für jeden Browser sehr unterschiedliche interne Strukturen.

In Chrome haben wir am oberen Rand des Shadow-DOM ein div, auf das wir nicht mehr zugreifen können. Dies war früher möglich, als /deep/ unterstützt wurde, aber dann wurde die Fähigkeit, die Shadow-Barriere zu durchdringen, als Bug angesehen, sodass eine einst nützliche Funktion gestrichen wurde. Innerhalb dieses div haben wir ein weiteres für die Spur und innerhalb des Spur-div ein drittes div für den Schieberegler. Diese letzten beiden sind beide klar mit einem id-Attribut gekennzeichnet, aber etwas anderes, das ich seltsam finde, ist, dass, während wir auf die Spur mit ::-webkit-slider-runnable-track und den Schieberegler mit ::-webkit-slider-thumb zugreifen können, nur das Spur-div ein pseudo-Attribut mit diesem Wert hat.

In Firefox sehen wir ebenfalls drei div-Elemente im Inneren, nur diesmal sind sie nicht verschachtelt – alle drei sind Geschwister. Darüber hinaus sind es einfach nur div-Elemente, die nicht durch ein Attribut gekennzeichnet sind, so dass wir bei der ersten Betrachtung keine Möglichkeit haben, welche Komponente welche ist. Glücklicherweise hebt die Auswahl im Inspektor die entsprechende Komponente auf der Seite hervor und so können wir feststellen, dass das erste die Spur ist, das zweite der Fortschritt und das dritte der Schieberegler.

Wir können auf die Spur (erstes div) mit ::-moz-range-track, den Fortschritt (zweites div) mit ::-moz-range-progress und den Schieberegler (letztes div) mit ::-moz-range-thumb zugreifen.

Die Struktur in Edge ist viel komplexer, was bis zu einem gewissen Grad eine größere Kontrolle über die Gestaltung des Schiebereglers ermöglicht. Wir können jedoch nur auf die Elemente mit -ms- Präfix-IDs zugreifen, was bedeutet, dass es auch viele Elemente gibt, auf die wir nicht zugreifen können, mit eingebauten Stilen, die wir oft ändern müssten, wie das overflow: hidden auf den Elementen zwischen dem eigentlichen input und seiner Spur oder dem transition auf dem Elternteil des Schiebereglers.

Eine andere Struktur zu haben und nicht auf alle Elemente im Inneren zugreifen zu können, um alles nach Wunsch zu gestalten, macht es sehr schwierig, wenn nicht sogar unmöglich, das gleiche Ergebnis in allen Browsern zu erzielen, auch wenn die Verwendung eines anderen Pseudo-Elements für jeden Browser beim Setzen individueller Stile hilft.

Wir sollten immer bestrebt sein, individuelle Stile auf ein Minimum zu beschränken, aber manchmal ist es einfach nicht möglich, da das Setzen des gleichen Stils sehr unterschiedliche Ergebnisse liefern kann, da unterschiedliche Strukturen vorhanden sind. Zum Beispiel würden das Setzen von Eigenschaften wie opacity, filter oder sogar transform auf der Spur auch den Schieberegler in Chrome und Edge beeinflussen (wo er ein Kind/Nachkomme der Spur ist), aber nicht in Firefox (wo er ein Geschwister ist).

Der effizienteste Weg, den ich gefunden habe, um gemeinsame Stile zu setzen, ist die Verwendung eines Sass-Mixins, da Folgendes nicht funktionieren wird

input::-webkit-slider-runnable-track, 
input::-moz-range-track, 
input::-ms-track { /* common styles */ }

Damit es funktioniert, müssten wir es so schreiben

input::-webkit-slider-runnable-track { /* common styles */ }
input::-moz-range-track { /* common styles */ }
input::-ms-track { /* common styles */ }

Aber das ist viel Wiederholung und ein Wartungsalbtraum. Das macht die Mixin-Lösung zur vernünftigsten Option: Wir müssen die gemeinsamen Stile nur einmal schreiben, also wenn wir beschließen, etwas in den gemeinsamen Stilen zu ändern, müssen wir diese Änderung nur an einer Stelle vornehmen – im Mixin.

@mixin track() { /* common styles */ }

input {
  &::-webkit-slider-runnable-track { @include track }
  &::-moz-range-track { @include track }
  &::-ms-track { @include track }
}

Beachten Sie, dass ich hier Sass verwende, aber Sie können jeden anderen Präprozessor verwenden. Was auch immer Sie bevorzugen, ist gut, solange es Wiederholungen vermeidet und den Code leichter wartbar macht.

Anfängliche Stile

Als Nächstes werfen wir einen Blick auf einige der Standardstile, die der Schieberegler und seine Komponenten mitbringen, um besser zu verstehen, welche Eigenschaften explizit gesetzt werden müssen, um visuelle Inkonsistenzen zwischen den Browsern zu vermeiden.

Nur eine Vorwarnung: Die Dinge sind unübersichtlich und kompliziert. Nicht nur, dass wir in verschiedenen Browsern unterschiedliche Standardwerte haben, sondern auch die Änderung einer Eigenschaft bei einem Element kann ein anderes unerwartet beeinflussen (zum Beispiel ändert das Setzen eines background auch die color und fügt einen border hinzu).

WebKit-Browser und Edge (denn ja, Edge wendet auch viele WebKit-präfixierte Dinge an) haben auch zwei Ebenen von Standardwerten für bestimmte Eigenschaften (z. B. die, die sich auf Abmessungen, Rahmen und Hintergründe beziehen), wenn wir sie so nennen dürfen – bevor -webkit-appearance: none gesetzt wird (ohne das die von uns gesetzten Stile in diesen Browsern nicht funktionieren) und nachdem es gesetzt wurde. Der Fokus wird jedoch auf den Standardwerten nach dem Setzen von -webkit-appearance: none liegen, denn in WebKit-Browsern können wir das Range-Input nicht gestalten, ohne dies zu setzen, und der ganze Grund, warum wir das hier durchgehen, ist zu verstehen, wie wir uns das Leben beim Gestalten von Schiebereglern erleichtern können.

Beachten Sie, dass das Setzen von -webkit-appearance: none auf dem Range-input und auf dem Schieberegler (die Spur hat es aus irgendeinem Grund bereits standardmäßig gesetzt) dazu führt, dass der Schieberegler in Chrome und Edge vollständig verschwindet. Warum das passiert, werden wir etwas später in diesem Artikel besprechen.

Das eigentliche Range-Input-Element

Die erste Eigenschaft, die ich überprüft habe, box-sizing, hat zufällig in allen Browsern denselben Wert – content-box. Das können wir sehen, indem wir die Eigenschaft box-sizing im Tab Berechnet in DevTools nachschlagen.

Leider ist das kein Indikator für das Kommende. Das wird offensichtlich, sobald wir uns die Eigenschaften ansehen, die uns die Boxen des Elements geben – margin, border, padding, width, height.

Standardmäßig ist der margin in Chrome und Edge 2px und in Firefox 0 .7em.

Bevor wir weitermachen, sehen wir uns an, wie wir die obigen Werte erhalten haben. Die berechneten Längenwerte, die wir erhalten, sind immer px-Werte.

Chrome zeigt uns jedoch, wie Browserstile gesetzt wurden (die Regel des Benutzeragenten-Stylesheets wird auf grauem Hintergrund angezeigt). Manchmal wurden die berechneten Werte nicht explizit gesetzt, so dass dies nutzlos ist, aber in diesem speziellen Fall können wir sehen, dass der margin tatsächlich als px-Wert gesetzt wurde.

Firefox lässt uns auch die Quelle der Browserstile in einigen Fällen verfolgen, wie in der folgenden Screenshot gezeigt

Dies funktioniert jedoch in diesem speziellen Fall nicht, daher können wir die berechneten Werte in DevTools nachsehen und dann prüfen, ob sich diese berechneten Werte in einer der folgenden Situationen ändern

1. Beim Ändern der font-size auf dem input oder auf dem html, was darauf hindeutet, dass es als em- oder rem-Wert gesetzt wurde.
2. Beim Ändern des Viewports, was darauf hindeutet, dass der Wert mit %-Werten oder Viewport-Einheiten gesetzt wurde. Dies kann in vielen Fällen wahrscheinlich übersprungen werden.

Das Gleiche gilt für Edge, wo wir verfolgen können, woher Benutzerstile stammen, aber nicht Browserstile, daher müssen wir prüfen, ob der berechnete px-Wert von etwas anderem abhängt.

In jedem Fall bedeutet dies, dass margin eine Eigenschaft ist, die wir explizit im input[type='range'] setzen müssen, wenn wir ein konsistentes Aussehen über die Browser hinweg erzielen wollen.

Da wir die font-size erwähnt haben, wollen wir auch diese überprüfen. Sicherlich ist auch diese inkonsistent.

Zuerst haben wir 13.3333px in Chrome, und trotz der Dezimalstellen, die darauf hindeuten könnten, dass es das Ergebnis einer Berechnung ist, bei der wir eine Zahl durch ein Vielfaches von 3 dividiert haben, scheint es so gesetzt worden zu sein und hängt nicht von den Viewport-Dimensionen oder der übergeordneten oder Stamm-font-size ab.

Firefox zeigt uns denselben berechneten Wert an, nur scheint dieser aus dem Setzen der font-Kurzform auf -moz-field zu stammen, was mich anfangs sehr verwirrte, besonders da background-color auf -moz-Field gesetzt ist, was dasselbe sein sollte, da CSS-Schlüsselwörter nicht zwischen Groß- und Kleinschreibung unterscheiden. Aber wenn sie gleich sind, wie kann es dann ein gültiger Wert für beide Eigenschaften sein? Anscheinend ist dieses Schlüsselwort eine Art Alias dafür, dass das Input wie jedes Input auf dem aktuellen Betriebssystem aussieht.

Schließlich gibt uns Edge 16px für seinen berechneten Wert und das scheint entweder vom Elternteil geerbt zu sein oder als 1em gesetzt zu sein, wie die folgende Aufzeichnung zeigt

Dies ist wichtig, da wir oft die Abmessungen von Schiebereglern und Bedienelementen (und ihren Komponenten) im Allgemeinen mit em-Einheiten festlegen wollen, damit ihre Größe relativ zur Textgröße auf der Seite gleich bleibt – sie sehen nicht zu klein aus, wenn wir die Textgröße erhöhen, oder zu groß, wenn wir die Textgröße verringern. Und wenn wir Abmessungen in em-Einheiten festlegen, führt ein spürbarer Unterschied in der font-size zwischen den Browsern dazu, dass unser Range-input in einigen Browsern kleiner und in anderen größer ist.

Aus diesem Grund stelle ich immer sicher, dass ich explizit eine font-size auf dem eigentlichen Schieberegler setze. Oder ich setze die font-Kurzform, auch wenn die anderen schriftartbezogenen Eigenschaften hier im Moment keine Rolle spielen. Vielleicht werden sie es in Zukunft tun, aber dazu später mehr, wenn wir über Ticks und Tick-Beschriftungen sprechen.

Bevor wir zu den Rahmen übergehen, sehen wir uns zuerst die Eigenschaft color an. In Chrome ist dies rgb(196,196,196) (so gesetzt), was es etwas heller als silver (rgb(192,192,192)/ #c0c0c0) macht, während in Edge und Firefox der berechnete Wert rgb(0,0,0) (also volles black) ist. Wir haben keine Möglichkeit zu wissen, wie dieser Wert in Edge gesetzt wurde, aber in Firefox wurde er über ein weiteres ähnliches Schlüsselwort gesetzt, -moz-fieldtext.

Der border ist in Chrome auf initial gesetzt, was äquivalent zu none medium currentcolor ist (Werte für border-style, border-width und border-color). Wie dick ein medium-Rahmen genau ist, hängt vom Browser ab, obwohl er überall mindestens so dick ist wie ein thin. Insbesondere in Chrome beträgt der hier erhaltene berechnete Wert 0.

In Firefox haben wir ebenfalls einen Wert von none medium currentcolor für den border, obwohl hier medium äquivalent zu 0.566667px zu sein scheint, ein Wert, der nicht von der Element- oder Stamm-font-size oder den Viewport-Dimensionen abhängt.

Wir können nicht sehen, wie alles in Edge gesetzt wurde, aber die berechneten Werte für border-style und border-width sind none bzw. 0. Die border-color ändert sich, wenn wir die Eigenschaft color ändern, was bedeutet, dass sie, wie in den anderen Browsern auch, auf currentcolor gesetzt ist.

Der padding ist in Chrome und Edge jeweils 0.

Wenn wir jedoch ein pixelgenaues Ergebnis wünschen, müssen wir ihn explizit setzen, da er in Firefox auf 1px gesetzt ist.

Machen wir nun einen weiteren Umweg und schauen uns die Hintergründe an, bevor wir versuchen, die Werte für die Abmessungen zu verstehen. Hier erhalten wir, dass der berechnete Wert transparent/ rgba(0, 0, 0, 0) in Edge und Firefox ist, aber rgb(255,255,255) (volles white) in Chrome.

Und... endlich, schauen wir uns die Abmessungen an. Ich habe das bis zum Schluss aufgespart, weil hier die Dinge wirklich chaotisch werden.

Chrome und Edge geben uns beide 129px für den berechneten Wert der width. Anders als bei früheren Eigenschaften können wir dies in Chrome nirgendwo gesetzt sehen, was mich normalerweise glauben lassen würde, dass es etwas ist, das entweder vom Elternteil abhängt, sich horizontal erstreckt, um zu passen, wie alle block-Elemente es tun (was hier definitiv nicht der Fall ist), oder von den Kindern abhängt. Es gibt auch eine Eigenschaft -webkit-logical-width, die im Computed-Panel denselben Wert von 129px hat. Das hat mich anfangs etwas verwirrt, aber es stellt sich heraus, dass es das äquivalente Äquivalent bezüglich der Schreibrichtung ist – mit anderen Worten, es ist die width für horizontale Schreibrichtung und die height für vertikale Schreibrichtung.

In jedem Fall hängt er in beiden Browsern nicht von der font-size des input selbst oder der des Stammelements oder von den Viewport-Dimensionen ab.

Firefox ist hier die Ausnahme und gibt einen berechneten Wert von 160px für die Standard-width zurück. Dieser berechnete Wert hängt jedoch von der font-size des Range-input ab – er scheint 12em zu sein.

Im Falle der height stimmen Chrome und Edge wieder überein und geben uns einen berechneten Wert von 21px. Genau wie bei der width kann ich dies in Chrome DevTools nirgendwo in der Benutzeragenten-Stylesheet-Regel sehen, was normalerweise passiert, wenn die height eines Elements von seinem Inhalt abhängt.

Dieser Wert hängt auch in keinem der Browser von der font-size ab.

Firefox ist wieder anders und gibt uns 17.3333px als berechneten Wert und das hängt, wieder, von der font-size des input ab – es sind 1.3em.

Aber das ist nicht schlimmer als der margin-Fall, oder? Nun, bisher nicht! Aber das wird sich bald ändern, denn wir gehen jetzt zur Spur-Komponente über.

Die Range-Spur-Komponente

Es gibt noch eine weitere Möglichkeit bezüglich der tatsächlichen input-Dimensionen, die wir noch nicht berücksichtigt haben: dass sie von denen ihrer Komponenten beeinflusst werden. Setzen wir also explizit einige Dimensionen auf die Spur und sehen wir, ob dies die Größe des Schiebereglers beeinflusst.

Anscheinend ändert sich in dieser Situation nichts für den eigentlichen Schieberegler im Falle der width, aber wir können weitere Inkonsistenzen bei der Spur-width feststellen, die sich standardmäßig in allen drei Browsern erstreckt, um den content-box des übergeordneten input auszufüllen.

In Firefox, wenn wir explizit eine width setzen, dann nimmt die Spur diese width, die wir ihr geben, und dehnt sich außerhalb ihres übergeordneten Schiebereglers aus oder schrumpft hinein, bleibt aber immer mittig ausgerichtet. Nicht schlecht, aber leider verhält sich Firefox als einziger Browser hier vernünftig.

In Chrome wird die von uns gesetzte Spur-width komplett ignoriert und es scheint keine vernünftige Möglichkeit zu geben, ihr einen Wert zu geben, der nicht von dem des übergeordneten Schiebereglers abhängt.

Was wahnsinnige Wege angeht, scheint die Verwendung von transform: scaleX(factor) die einzige Möglichkeit zu sein, die Spur breiter oder schmaler als ihren übergeordneten Schieberegler zu machen. Beachten Sie, dass dies auch zu einer Reihe von Nebenwirkungen führt. Der Schieberegler wird ebenfalls horizontal skaliert und seine Bewegung ist in Chrome und Edge auf die skalierten Spuren beschränkt (da der Schieberegler in diesen Browsern ein Kind der Spur ist), aber nicht in Firefox, wo seine Größe beibehalten wird und seine Bewegung weiterhin auf das Input beschränkt ist, nicht auf die skalierte Spur (da Spur und Schieberegler hier Geschwister sind). Jede seitliche padding, border oder margin auf der Spur wird ebenfalls skaliert.

Weiter zu Edge, die Spur nimmt wieder jede width an, die wir setzen.

Dies ist jedoch nicht dieselbe Situation wie in Firefox. Während das Setzen einer width, die größer ist als die des übergeordneten Schiebereglers, dazu führt, dass sich die Spur nach außen ausdehnt, sind die beiden nicht mittig ausgerichtet. Stattdessen ist die linke Kante der Spur mit der linken Inhaltgrenze ihres Range-input-Elternteils ausgerichtet. Diese Ausrichtungsin konsistenz allein wäre kein großes Problem – ein margin-left, der nur auf ::-ms-track gesetzt ist, könnte es beheben.

Alles, was sich außerhalb der content-box des übergeordneten Schiebereglers befindet, wird jedoch in Edge abgeschnitten. Dies entspricht nicht dem Setzen von overflow auf hidden auf dem eigentlichen input, was alles außerhalb der padding-box abschneiden würde, nicht der content-box. Daher kann dies nicht durch Setzen von overflow: visible auf dem Schieberegler behoben werden.

Dieses Beschneiden wird durch die Elemente zwischen dem input und der Spur verursacht, die overflow: hidden haben, aber da wir auf diese nicht zugreifen können, können wir dieses Problem auch nicht beheben. Das Setzen von allem so, dass keine Komponente (einschließlich ihrer box-shadow) über die content-box des Range hinausgeht, ist in einigen Fällen eine Option, aber nicht immer.

Für die height verhält sich Firefox ähnlich wie bei der width. Die Spur dehnt sich vertikal auf die von uns gesetzte height aus oder schrumpft, ohne den übergeordneten Schieberegler zu beeinflussen, und bleibt immer vertikal mittig ausgerichtet.

Der Standardwert für diese height ohne gesetzte Stile auf dem eigentlichen input oder der Spur ist .2em.

Im Gegensatz zum Fall der width erlaubt Chrome der Spur, die von uns gesetzte height anzunehmen, und wenn wir hier keine %-Einheit verwenden, erweitert oder schrumpft auch die content-box des übergeordneten Schiebereglers so, dass die border-box der Spur perfekt hineinpasst. Bei Verwendung einer %-Einheit sind der eigentliche Schieberegler und die Spur vertikal mittig ausgerichtet.

Der berechnete Wert, den wir für die height ohne eigene Stile erhalten, ist derselbe wie für den Schieberegler und ändert sich nicht mit der font-size.

Was ist mit Edge? Nun, wir können die height der Spur unabhängig von der des übergeordneten Schiebereglers ändern und beide bleiben vertikal mittig ausgerichtet, aber das alles nur, solange die Spur-height, die wir setzen, kleiner ist als die ursprüngliche height des tatsächlichen input. Darüber hinaus ist die berechnete height der Spur immer gleich der des übergeordneten Range.

Die ursprüngliche Spur-Höhe beträgt 11px und dieser Wert hängt weder von der font-size noch vom Viewport ab.

Kommen wir zu etwas weniger Verwirrendem, wir haben box-sizing. Dies ist border-box in Chrome und content-box in Edge und Firefox. Wenn wir also eine border oder padding ungleich Null haben, dann ist box-sizing eine Eigenschaft, die wir explizit setzen müssen, um die Dinge auszugleichen.

Die Standard-margin und padding der Spur sind in allen drei Browsern 0 – endlich eine Oase der Konsistenz!

Die Werte für die color-Eigenschaft können in allen drei Browsern vom übergeordneten Schieberegler geerbt werden.

Dennoch ist Edge die Ausnahme und ändert sie auf white, obwohl das Setzen auf initial sie auf black ändert, was der Wert ist, den wir für das eigentliche input haben.

Das Setzen von -webkit-appearance: none auf dem eigentlichen input in Edge führt dazu, dass der berechnete Wert der color auf der Spur transparent ist (wenn wir keinen color-Wert explizit selbst gesetzt haben). Außerdem, sobald wir einen background auf der Spur hinzufügen, ändert sich die berechnete Spur-color plötzlich zu black.

Bis zu einem gewissen Grad ist die Fähigkeit, die color-Eigenschaft zu erben, für das Theming nützlich, obwohl das Erben von benutzerdefinierten Eigenschaften hier viel mehr bewirken kann. Betrachten wir zum Beispiel, dass wir Silber für sekundäre Dinge und Orange für das verwenden wollen, was wir hervorheben wollen. Wir können zwei CSS-Variablen auf dem Body definieren und sie dann seitenweit verwenden, sogar innerhalb unserer Range-Inputs.

body {
  --fading: #bbb;
  --impact: #f90
}

h2 { border-bottom: solid .125em var(--impact) }

h6 { color: var(--fading) }

[type='range']:focus { box-shadow: 0 0 2px var(--impact) }

@mixin track() { background: var(--fading) }

@mixin thumb() { background: var(--impact) }

Leider funktioniert das zwar in Chrome und Firefox, aber Edge erlaubt derzeit nicht, dass benutzerdefinierte Eigenschaften auf dem Range-input an seine Komponenten weitergegeben werden.

Standardmäßig gibt es keinen border auf der Spur in Chrome oder Firefox (border-width ist 0 und border-style ist none).

Edge hat keinen border auf der Spur, wenn wir keinen background auf dem eigentlichen Input gesetzt haben und keinen background auf der Spur selbst gesetzt haben. Sobald sich dies jedoch ändert, erhalten wir einen dünnen (1px) black Spur-border.

Die Standard-background-color wird als weiß geerbt angezeigt, aber dann erhalten wir irgendwie einen berechneten Wert von rgba(0,0,0,0) (transparent) in Chrome (sowohl vor als auch nach -webkit-appearance: none). Das lässt mich auch fragen, wie wir die Spur vorher sehen können, da es keine background-color oder background-image gibt, die uns etwas Sichtbares geben würden. Firefox gibt uns einen berechneten Wert von rgb(153,153,153) (#999) und Edge transparent (obwohl wir vielleicht ursprünglich denken, es sei eine Art Silber, das ist nicht der background des ::-ms-track-Elements – dazu später mehr).

Die Range-Schieberegler-Komponente

Bereit für die nervigste Inkonsistenz überhaupt? Der Schieberegler bewegt sich innerhalb der Grenzen der content-box der Spur in Chrome und innerhalb der Grenzen der content-box des eigentlichen input in Firefox und Edge, selbst wenn wir die Spur länger oder kürzer als das input machen (Chrome erlaubt dies nicht und zwingt die border-box der Spur horizontal in die content-box des Schiebereglers).

Die Funktionsweise von Chrome wird unten veranschaulicht

Der Padding ist transparent, während die Content-Box und der Rand semitransparent sind. Wir haben Orange für den eigentlichen Schieberegler, Rot für die Spur und Lila für den Schieberegler verwendet.

Für Firefox sind die Dinge etwas anders

In Chrome ist der Daumen das Kind der Schiene, während er in Firefox ihr Geschwister ist. Wenn man es also so betrachtet, ist es sinnvoll, dass Chrome den Daumen innerhalb der Grenzen der content-box der Schiene bewegt und Firefox ihn innerhalb der Grenzen der content-box des Schiebereglers bewegt. Allerdings befindet sich der Daumen auch in Edge innerhalb der Schiene und bewegt sich immer noch innerhalb der Grenzen der content-box des Schiebereglers.

Obwohl dies auf den ersten Blick sehr seltsam aussieht, liegt es daran, dass Edge die position der Schiene auf static erzwingt und wir das nicht ändern können, selbst wenn wir sie mit !important auf relative setzen.

Das bedeutet, wir können unseren Schieberegler für alle Browser genau gleich gestalten, aber wenn seine content-box horizontal nicht mit der seiner Schiene übereinstimmt (wenn wir also eine seitliche padding oder einen border auf der Schiene mit einem Wert ungleich Null haben), wird er sich nicht in allen Browsern innerhalb derselben Grenzen bewegen.

Wenn wir die Schiene horizontal skalieren, verhalten sich Chrome und Firefox wie zuvor, wobei sich der Daumen innerhalb der Grenzen der nun skalierten content-box der Schiene in Chrome und innerhalb der Grenzen der content-box des tatsächlichen input in Firefox bewegt. Edge lässt den Daumen jedoch innerhalb eines Intervalls gleiten, dessen Breite der border-box der Schiene entspricht, das aber vom linken Rand der padding-box der Schiene ausgeht, was wahrscheinlich darauf zurückzuführen ist, dass die transform-Eigenschaft einen Stacking Context erzeugt.

Vertikal ist der Daumen in Firefox mittig zur Schiene ausgerichtet, in Edge scheinbar mittig, obwohl ich bei mehreren Tests derselben Situation sehr verwirrende, unterschiedliche Ergebnisse erzielt habe, und die Oberseite seiner border-box mit der Oberseite der content-box der Schiene in Chrome ausgerichtet ist, sobald wir -webkit-appearance: none auf dem tatsächlichen input und auf dem Daumen setzen, damit wir den Schieberegler gestalten können.

Obwohl die Chrome-Entscheidung auf den ersten Blick seltsam erscheint, ärgerlich in den meisten Fällen ist und sich sogar kürzlich zum Bruch von Dingen in… Edge ausgewirkt hat (aber dazu später mehr), steckt eine gewisse Logik dahinter. Standardmäßig wird die height der Schiene in Chrome durch die des Daumens bestimmt, und wenn wir die Dinge so betrachten, erscheint die obere Ausrichtung nicht mehr als völliger Wahnsinn.

Wir möchten jedoch oft einen Daumen, der größer ist als die Höhe der Schiene und mittig zur Schiene ausgerichtet ist. Wir können die Chrome-Ausrichtung mit margin-top in den Stilen korrigieren, die wir auf der ::-webkit-slider-thumb-Pseudo setzen.

Leider brechen wir damit die vertikale Ausrichtung in Edge. Das liegt daran, dass Edge jetzt auch die Stile anwendet, die über ::-webkit-slider-thumb gesetzt wurden. Zumindest haben wir die Möglichkeit, margin-top auf 0 in den Stilen zurückzusetzen, die wir auf ::-ms-thumb setzen. Die folgende Demo zeigt ein sehr einfaches Beispiel dafür.

Siehe den Pen von thebabydino (@thebabydino) auf CodePen.

Genau wie bei der Schiene ist der Wert der box-sizing-Eigenschaft in Chrome border-box und in Edge und Firefox content-box. Daher müssen wir ihn explizit setzen, wenn wir eine border oder padding mit einem Wert ungleich Null auf dem Daumen haben möchten, um konsistente Ergebnisse über Browser hinweg zu erzielen.

margin und padding sind standardmäßig in allen drei Browsern 0.

Nachdem -webkit-appearance: none sowohl auf den Schieberegler als auch auf den Daumen gesetzt wurde (das Setzen nur auf eines der beiden hat keine Auswirkung), werden die Abmessungen des Daumens von 10x21 (Abmessungen, die nicht von der font-size abhängen) auf 129x0 in Chrome zurückgesetzt. Die height der Schiene und des tatsächlichen Schiebereglers werden ebenfalls auf 0 zurückgesetzt, da sie von der ihres Inhalts abhängen (dem Daumen darin, dessen height 0 geworden ist).

Das ist auch der Grund, warum das explizite Setzen einer height auf dem Daumen dazu führt, dass die Schiene dieselbe height annimmt.

Laut Chrome DevTools gibt es in keinem der Fälle einen border, obwohl er vor dem Setzen von -webkit-appearance: none definitiv vorhanden zu sein scheint.

Wenn das kein border ist, könnte es ein outline oder ein box-shadow ohne Weichzeichnung und mit positiver Ausdehnung sein. Aber laut Chrome DevTools haben wir weder einen outline noch einen box-shadow auf dem Daumen.

Das Setzen von -webkit-appearance: none in Edge bewirkt, dass die Abmessungen des Daumens von 11x11 (Werte, die nicht von der font-size abhängen) auf 0x0 gehen. Das explizite Setzen einer height auf dem Daumen bewirkt, dass die Schiene die anfängliche height (11px) annimmt.

In Edge gibt es anfänglich keinen border auf dem Daumen. Nachdem wir jedoch eine background auf dem tatsächlichen Range-input oder auf einem seiner Komponenten gesetzt haben, erhalten wir plötzlich einen seitlichen solid 1px white (links und rechts, aber nicht oben und unten), der sich visuell im :active-Zustand in black verwandelt (obwohl Edge DevTools das nicht zu bemerken scheint). Das Setzen von -webkit-appearance: none entfernt die border-width.

In Firefox haben wir ohne das Setzen einer Eigenschaft wie background auf dem Range-input oder seinen Komponenten die Abmessungen des Daumens von 1.666x3.333, und in diesem Fall ändern sie sich nicht mit der font-size. Wenn wir jedoch so etwas wie background: transparent auf dem Schieberegler setzen (oder irgendeinen background-Wert auf seinen Komponenten), werden sowohl die width als auch die height des Daumens 1em.

In Firefox haben wir, wenn wir dem glauben, was wir in DevTools sehen, anfänglich einen soliden, dicken grauen (rgb(153, 153, 153)) border.

Visuell kann ich diesen dicken grauen border jedoch nirgends erkennen.

Nachdem ein background auf dem tatsächlichen Range-input oder einer seiner Komponenten gesetzt wurde, wird der Daumen-border tatsächlich visuell erkennbar und scheint .1em zu betragen.

In Chrome und Edge ist border-radius immer 0.

In Firefox haben wir jedoch einen Wert von .5em für diese Eigenschaft, sowohl vor als auch nach dem Setzen eines background auf dem Range-input oder seinen Komponenten, obwohl die anfängliche Form des Daumens nicht wie ein Rechteck mit abgerundeten Ecken aussieht.

Die seltsame anfängliche Form des Daumens in Firefox hat mich vermuten lassen, dass ihm vielleicht ein clip-path gesetzt ist, aber laut DevTools ist das nicht der Fall.

Wahrscheinlicher ist, dass die Daumenform aufgrund der -moz-field-Einstellung zustande kommt, obwohl sie zumindest auf Windows 10 nicht wie jeder andere Schieberegler aussieht.

Die background-color des Daumens wird von Chrome DevTools als rgba(0, 0, 0, 0) (transparent) gemeldet, obwohl er vor dem Setzen von -webkit-appearance: none grau aussieht. Wir scheinen auch keinen background-image zu haben, der den Farbverlauf oder die Linien auf dem Daumen vor dem Setzen von -webkit-appearance: none erklären könnte. Firefox DevTools meldet ihn als rgb(240, 240, 240), obwohl er blau aussieht, solange wir keinen background explizit auf dem tatsächlichen Range-input oder einem seiner Komponenten gesetzt haben.

In Edge ist die background-color rgb(33, 33, 33) vor dem Setzen von -webkit-appearance: none und transparent danach.

Die Range-Progress (Füll-)Komponente

Wir haben nur dedizierte Pseudo-Elemente dafür in Firefox (::-moz-range-progress) und in Edge (::-ms-fill-lower). Beachten Sie, dass dieses Element in Firefox ein Geschwister der Schiene und in Edge ein Nachfahre ist. Das bedeutet, dass es relativ zum tatsächlichen input in Firefox dimensioniert wird, aber relativ zur Schiene in Edge.

Um dies besser zu verstehen, betrachten Sie, dass die border-box der Schiene horizontal perfekt in die content-box des Schiebereglers passt und dass die Schiene sowohl einen border als auch eine padding hat.

In Firefox fällt die linke Grenze der border-box der Progress-Komponente immer mit der linken Grenze der content-box des Schiebereglers zusammen. Wenn der aktuelle Wert des Schiebereglers sein Minimalwert ist, fällt die rechte Grenze der border-box unseres Progresses ebenfalls mit der linken Grenze der content-box des Schiebereglers zusammen. Wenn der aktuelle Wert des Schiebereglers sein Maximalwert ist, fällt die rechte Grenze der border-box unseres Progresses mit der rechten Grenze der content-box des Schiebereglers zusammen.

Das bedeutet, die width der border-box unseres Progress geht von 0 bis zur width der content-box des Schiebereglers. Im Allgemeinen, wenn sich der Daumen bei x% des Abstands zwischen den beiden Grenzwerten befindet, beträgt die width der border-box für unseren Progress x% der Breite der content-box des Schiebereglers.

Dies wird in der folgenden Aufnahme gezeigt. Der padding-Bereich ist immer transparent, während der border-Bereich und die content-box semitransparent sind (orange für das tatsächliche input, rot für die Schiene, grau für den Progress und lila für den Daumen).

In Edge fällt die linke Grenze der border-box des Füllmaterials jedoch immer mit der linken Grenze der content-box der Schiene zusammen, während die rechte Grenze der border-box des Füllmaterials immer mit der vertikalen Linie zusammenfällt, die die border-box des Daumens in zwei gleiche Hälften teilt. Das bedeutet, dass, wenn der aktuelle Wert des Schiebereglers sein Minimalwert ist, die rechte Grenze der border-box des Füllmaterials halb so breit ist wie die border-box des Daumens rechts von der linken Grenze der content-box der Schiene. Und wenn der aktuelle Wert des Schiebereglers sein Maximalwert ist, ist die rechte Grenze der border-box des Füllmaterials halb so breit wie die border-box des Daumens links von der rechten Grenze der content-box der Schiene.

Das bedeutet, dass die width der border-box unseres Progress von der halben width der border-box des Daumens minus der linken border und padding der Schiene bis zur width der content-box der Schiene plus der rechten padding und border der Schiene minus der halben width der border-box des Daumens reicht. Im Allgemeinen, wenn sich der Daumen bei x% des Abstands zwischen den beiden Grenzwerten befindet, ist die width der border-box für unseren Progress ihre minimale width plus x% der Differenz zwischen ihrer maximalen und minimalen width.

Dies wird alles durch die folgende Aufnahme von diesem Live-Demo veranschaulicht, mit dem Sie spielen können.

Obwohl die Beschreibung des Edge-Ansatzes oben ihn komplizierter erscheinen lassen mag, bin ich zu dem Schluss gekommen, dass dies der beste Weg ist, die Breite dieser Komponente zu variieren, da der Firefox-Ansatz einige Probleme verursachen kann.

Betrachten Sie zum Beispiel den Fall, dass wir keine border oder padding auf der Schiene für browserübergreifende Konsistenz haben und die height sowohl der border-box des Füllmaterials als auch des Daumens der border-box der Schiene entspricht. Darüber hinaus ist der Daumen eine Scheibe (border-radius: 50%).

In Edge ist alles in Ordnung.

Aber in Firefox sehen die Dinge unbeholfen aus (Live-Demo).

Die gute Nachricht ist, dass wir bei dieser Komponente keine weiteren ärgerlichen und schwer zu umgehenden Inkonsistenzen haben.

box-sizing hat in beiden Browsern denselben berechneten Wert – content-box.

In Firefox beträgt die height des Progress .2em, während padding, border und margin alle 0 sind.

In Edge entspricht die height des Füllmaterials der content-box der Schiene, wobei padding, border und margin alle 0 sind, genau wie in Firefox.

Anfänglich ist der background dieses Elements rgba(0, 0, 0, 0) (transparent, weshalb wir ihn zuerst nicht sehen) in Firefox und rgb(0, 120, 115) in Edge.

In beiden Fällen ist der berechnete Wert der color-Eigenschaft rgb(0, 0, 0) (vollständig black).

WebKit-Browser stellen keine solche Komponente bereit, und da wir keinen Zugriff mehr auf die ::before- oder ::after-Pseudoelemente einer Schiene haben und sie nicht verwenden können, bleibt unsere einzige Option, dies zu emulieren, das Überlagern eines zusätzlichen, nicht wiederholenden backgrounds über dem vorhandenen Hintergrund der Schiene für diese Browser und die Größenanpassung dieser zusätzlichen Ebene entlang der x-Achse abhängig vom aktuellen Wert des Range-input.

Der einfachste Weg, dies heutzutage zu tun, ist die Verwendung einer CSS-Variablen --val für den aktuellen Wert, die den aktuellen Wert des Schiebereglers speichert. Wir aktualisieren diese Variable jedes Mal, wenn sich der Wert des Schiebereglers ändert, und machen die background-size dieser oberen Ebene zu einem calc()-Wert, der von --val abhängt. Auf diese Weise müssen wir nichts neu berechnen, wenn sich der Wert des Range-input ändert – unser calc()-Wert ist dynamisch, sodass das Aktualisieren der --val-Variable ausreicht (nicht nur für diese background-size, sondern auch für andere Stile, die davon abhängen könnten).

Siehe den Pen von thebabydino (@thebabydino) auf CodePen.

Auch für Firefox ist dies eine Option, wenn die Art und Weise, wie ::-moz-range-progress zunimmt, für unseren speziellen Anwendungsfall nicht gut aussieht.

Edge bietet auch ::-ms-fill-upper, was im Grunde die Ergänzung zum unteren ist und es ist der silberne background dieses Pseudo-Elements, den wir anfänglich rechts vom Daumen sehen, nicht der der Schiene (die Schiene ist transparent).

Teilstriche und Beschriftungen

Edge ist der einzige Browser, der standardmäßig Teilstriche anzeigt. Sie werden auf der Schiene angezeigt und begrenzen zwei, fünf, zehn, zwanzig Abschnitte, die genaue Anzahl hängt anfänglich von der width der Schiene ab. Der einzige Stil, den wir für diese Teilstriche ändern können, ist die color-Eigenschaft, da diese von der Schiene geerbt wird (so entfernt das Setzen von color: transparent auf der Schiene die anfänglichen Teilstriche in Edge).

Die Spezifikation besagt, dass Teilstriche und Beschriftungen durch Verknüpfen eines datalist-Elements hinzugefügt werden können, für dessen option-Kinder wir ein label-Attribut angeben können, wenn wir möchten, dass dieser spezielle Teilstich auch eine Beschriftung hat.

Leider, wenn auch zu diesem Zeitpunkt nicht mehr überraschend, haben die Browser hier auch einen eigenen Kopf. Firefox zeigt nichts an – keine Teilstriche, keine Beschriftungen. Chrome zeigt die Teilstriche an, erlaubt uns aber nur, ihre Position entlang des Schiebereglers mit den option-Werten zu steuern. Es erlaubt uns nicht, sie in irgendeiner Weise zu gestalten, und es zeigt keine Beschriftungen an.

Außerdem verschwinden diese Teilstriche, wenn wir -webkit-appearance: none auf den tatsächlichen Schieberegler setzen (was wir tun müssen, um ihn gestalten zu können).

Edge schließt sich dem an und zeigt ebenfalls keine Beschriftungen an und erlaubt nur wenig Kontrolle über das Aussehen der Teilstriche. Während das Hinzufügen des datalist uns erlaubt zu steuern, welche Teilstriche wo auf der Schiene angezeigt werden, können wir sie nicht über das Ändern der color-Eigenschaft auf der Schienenkomponente hinaus gestalten.

In Edge haben wir auch die Pseudo-Elemente ::-ms-ticks-before und ::-ms-ticks-after. Diese sind ziemlich selbsterklärend – Teilstriche vor und nach der Schiene. Es fällt mir jedoch schwer zu verstehen, wie sie wirklich funktionieren.

Sie sind durch display: none verborgen, so dass das Ändern dieser Eigenschaft auf block sie sichtbar macht, wenn wir auch explizit eine Schienen-height setzen, obwohl dies ihre eigene height nicht verändert.

Darüber hinaus können wir Eigenschaften wie margin, padding, height, background, color setzen, um ihr Aussehen zu steuern. Ich habe jedoch keine Ahnung, wie man die Dicke einzelner Teilstriche steuert, wie man einzelnen Teilstrichen Farbverläufe gibt oder wie man einige von ihnen als Haupt- und andere als Nebenstriche kennzeichnet.

Daher bleibt unsere beste Option, wenn wir ein schönes browserübergreifendes Ergebnis wünschen, die Verwendung von repeating-linear-gradient für die Teilstriche und das label-Element für die Werte, die diesen Teilstrichen entsprechen.

Siehe den Pen von thebabydino (@thebabydino) auf CodePen.

Tooltip/ Aktueller Wert-Anzeige

Edge ist der einzige Browser, der über ::-ms-tooltip einen Tooltip bereitstellt, aber dieser erscheint nicht im DOM, kann nicht wirklich gestaltet werden (wir können nur wählen, ihn zu verstecken, indem wir display: none darauf setzen) und kann nur ganze Zahlen anzeigen, sodass er für einen Range-input zwischen sagen wir .1 und .4 völlig nutzlos ist – alle Werte, die er anzeigt, sind 0!

Daher ist unsere beste Wahl, diesen einfach zu verstecken und das output-Element für alle Browser zu verwenden, wiederum unter Ausnutzung der Möglichkeit, den aktuellen Schiebereglerwert in einer --val-Variable zu speichern und dann einen calc()-Wert zu verwenden, der von dieser Variablen für die Position abhängt.

Siehe den Pen von thebabydino (@thebabydino) auf CodePen.

Ausrichtung

Die gute Nachricht ist, dass jeder Browser uns erlaubt, vertikale Schieberegler zu erstellen. Die schlechte Nachricht ist, wie Sie vielleicht erraten haben… jeder Browser bietet eine andere Methode dafür, von der die in der Spezifikation dargestellte (Setzen einer width kleiner als die height auf dem Range-input) keine ist. WebKit-Browser haben sich für -webkit-appearance: slider-vertical entschieden, Edge für writing-mode: bt-lr, während Firefox dies über ein orient-Attribut mit dem Wert 'vertical' steuert.

Die wirklich schlechte Nachricht ist, dass wir bei WebKit-Browsern, wenn wir einen Schieberegler auf diese Weise vertikal machen, keine benutzerdefinierten Stile darauf anwenden können (da das Anwenden benutzerdefinierter Stile einen Wert von none für -webkit-appearance erfordert).

Unsere beste Option ist, unseren Range-input einfach wie einen horizontalen zu gestalten und ihn dann mit einer CSS-transform-Regel zu drehen.

Siehe den Pen von thebabydino (@thebabydino) auf CodePen.