Eine überraschend häufige Antwort, wenn man Leute fragt, was sie an *irgendetwas* in CSS beheben würden, ist die Verbesserung der Handhabung von Viewport-Einheiten.
Ein Punkt, der oft zur Sprache kommt, ist, wie sie sich zu Scrollbalken verhalten. Wenn ein Element beispielsweise auf 100vw gesetzt und von Rand zu Rand gedehnt wird, ist das in Ordnung, solange die Seite keine vertikale Scrollleiste hat. Wenn sie eine vertikale Scrollleiste hat, dann ist 100vw zu breit, und das Vorhandensein dieser vertikalen Scrollleiste löst eine *horizontale* Scrollleiste aus, da Viewport-Einheiten keine elegante/optionale Möglichkeit haben, damit umzugehen. Man könnte also beispielsweise overflow auf dem body verstecken, obwohl man es sonst nicht müsste. ( Demo )
Ein weiteres Szenario betrifft mobile Browser. Sie könnten Viewport-Einheiten verwenden, um einen festen Footer am unteren Bildschirmrand zu positionieren. Aber dann kann die Browser-Oberfläche erscheinen (z. B. Navigation, Tastatur usw.) und den Footer verdecken, da der mobile Browser nichts über die Änderung der Viewport-Größe berücksichtigt.
Matt Smith dokumentiert dieses Problem
-webkit-fill-available anstelle von Viewport-Einheiten verwendet, um das Problem zu beheben.Und eine Art Lösung
body {
min-height: 100vh;
min-height: -webkit-fill-available;
}
html {
height: -webkit-fill-available;
}Das obige wurde aktualisiert, um sicherzustellen, dass das html-Element verwendet wird, da uns mitgeteilt wurde, dass Chrome das Verhalten an die Implementierung von Firefox anpassen wird.
Funktioniert das wirklich? [...] Ich hatte keine Probleme mit den von mir durchgeführten Tests und verwende diese Methode derzeit in der Produktion. Ich habe jedoch eine Reihe von Antworten auf meinen Tweet erhalten, die auf andere mögliche Probleme bei der Verwendung dieser Methode hinweisen (die Auswirkungen von rotierenden Geräten, Chrome ignoriert die Eigenschaft nicht vollständig usw.).
Es wäre besser, eines Tages eine echte Cross-Browser-Lösung dafür zu erhalten, aber ich sehe keine Probleme bei der Verwendung dieser Methode als progressive Verbesserung. Es ist seltsam, eine herstellerspezifische Eigenschaft als progressive Verbesserung zu verwenden, aber hey, die Welt ist seltsam.
Es ist nützlich, die Kommentare des verlinkten Artikels zu lesen, da sie sich mit weiteren Tests hierzu befassen. Es ist auch nützlich zu beachten, dass der hier verwendete Stil im Laufe der Zeit geändert wird. Solange dies als "progressive Verbesserung" betrachtet wird, wie Chris sagt, ist es in Ordnung, aber nicht, wenn Sie sich auf diese Funktion verlassen.
Persönlich kann ich den Tag kaum erwarten, an dem wir eine einfache und zuverlässige CSS-Lösung für das 100vh-Problem haben, ähnlich wie dieser Einzeiler. Die Tatsache, dass wir im Jahr 2020 immer noch keine Lösung dafür haben, ist lächerlich.
JS, aber ich mag Hiswe/vh-check: https://github.com/Hiswe/vh-check
Getestet
* Android 10 mit Chrome 83.0.4103.106
* iPad Mini 2 mit iOS 12.4
* iPhone SE (320 x 568vp) mit iOS 13.5
-webkit-fill-availablehat wie erwartet funktioniert.Ich habe dieses Problem mit Chrome gelöst und den Hack als PostCSS-Plugin veröffentlicht
https://github.com/postcss/postcss-100vh-fix
Es funktioniert ohne JS in allen Browsern.
Ich habe es ausprobiert und es scheint, dass Chrome und Firefox in den aktuellen Versionen keine Bindestriche unterstützen. Sowohl unter Android als auch unter Windows.
Es funktioniert nicht auf iPhone-Geräten, wenn ein festes Element vorhanden ist und die Tastatur geöffnet ist. Es verschiebt das Element nach oben, ohne die Viewport-Größe des Elements zu ändern.