David Chanin hat einen kurzen Artikel verfasst, der ein Problem zusammenfasst, wenn man die height eines Elements in mobilen Browsern auf 100vh setzt und dann auch noch etwas am unteren Rand davon positioniert.
Zusammengefasst in dieser Grafik
Das Problem ist, dass Chrome die Adressleiste (Browser-Chrome) nicht berücksichtigt, wenn sie angezeigt wird, was das Element verkürzt und den unteren Rand des Elements über den unteren Rand des tatsächlichen Viewports hinaus verschiebt.
<div class="full-page-element">
<button>Button</button>
</div>.full-page-element {
height: 100vh;
position: relative;
}
.full-page-element button {
position: absolute;
bottom: 10px;
left: 10px;
}Man würde erwarten, dass der Button in der Grafik sichtbar ist (vorausgesetzt, dieses Element befindet sich am oberen Rand der Seite und du hast nicht gescrollt), da er sich am unteren Rand eines 100vh-Elements befindet. Aber er ist tatsächlich hinter dem Browser-Chrome auf mobilen Browsern versteckt, einschließlich iOS Safari oder Android Chrome.
Ich benutze das oft
body {
height: 100vh; /* Nice to not have to think about the HTML element parent */
margin: 0;
}Es ist nur ein schneller Weg, um sicherzustellen, dass der Body die volle Höhe hat, ohne andere Elemente einzubeziehen. Ich mache das normalerweise bei eher unwichtigen Demo-Sachen, aber mir wird gesagt, dass selbst das ein wenig problematisch ist, da es zu Sprüngen kommen kann, wenn der Browser-Chrome erscheint und verschwindet, oder die Dinge sind vielleicht nicht ganz so zentriert, wie man es erwarten würde.
Man würde denken, dass man body { height: 100% } machen könnte, aber da gibt es auch einen Haken. Der Body ist ein Kind von <html>, das nur so hoch ist wie der Inhalt, den es enthält, genau wie jedes andere Element.
Wenn der Body die volle Höhe haben soll, musst du dich auch um das HTML-Element kümmern
html, body {
height: 100%;
}…was keine große Sache ist und eine zuverlässige browserübergreifende Konsistenz aufweist.
Es ist das Positionieren von Dingen am unteren Rand, das knifflig ist. Es ist problematisch wegen position: absolute; innerhalb des "voller Höhe" (oftmals höher als sichtbar) Containers.
Wenn du versuchst, etwas wie eine feste Navigationsleiste am unteren Bildschirmrand zu platzieren, würdest du das wahrscheinlich mit position: fixed; bottom: 0; tun, und das scheint gut zu funktionieren. Der Browser-Chrome verschiebt es nach oben und unten, wie erwartet (Video).
Horizontale Viewport-Einheiten sind aufgrund einer weiteren Browser-UI ebenso seltsam und problematisch: Scrollbalken. Wenn ein Browserfenster einen sichtbaren Scrollbalken hat, wird dieser normalerweise den sichtbaren Bereich beeinträchtigen, obwohl ein Wert von 100vw so berechnet wird, als wäre der Scrollbalken nicht da. Mit anderen Worten, 100vw verursacht horizontales Scrollen auf eine Weise, die du wahrscheinlich nicht erwarten würdest.
Siehe den Pen
CSS Vars für Viewport-Breite minus Scrollbalken von Shaw (@shshaw)
auf CodePen.
Unsere letzte CSS-Wunschliste erwähnte mehrmals eine bessere Handhabung von Viewport-Einheiten, daher sind Entwickler offensichtlich ziemlich daran interessiert, bessere Lösungen für diese Dinge zu haben. Ich bin mir aber nicht sicher, was das für die Webkompatibilität bedeuten würde, denn eine Änderung ihrer Funktionsweise könnte all die Workarounds brechen, die wir verwendet haben und die sicherlich noch im Umlauf sind.
Im obigen Beispiel möchte ich calc() minus der Höhe der Adressleiste hinzufügen :D
height: calc(100vh – 80px) /* 80px oder spiele damit, bis es passt ;) */
Ich benutze dasselbe und auf Produktionsseiten funktioniert es großartig!
Ich habe kürzlich etwas Ähnliches verwendet
um dasselbe Problem mit iOS Safari (glaube ich) zu lösen. Die zweite Zeile ist eine CSS-Eigenschaft. Ah. Und ich sehe gerade, dass es jetzt auch
-moz-availablegibt.Super!
fill-availablewurde aufgrund von Änderungen in den letzten Spezifikationen zustretchgeändert.Die korrekte Verwendung wäre also
das nach der Verwendung von Autoprefixer ergeben könnte (ich bin mir nicht sicher, welche Präfixe korrekt sind)
Außerdem gibt es ein React-Paket, das dieses Problem löst: https://www.npmjs.com/package/react-div-100vh
Chrome hat die Adressleiste früher berücksichtigt, aber das führte zu einem anderen Problem: Wenn die Adressleiste aus dem Blickfeld glitt, wurden alle deine Elemente, die vh-Einheiten verwenden, automatisch an die neue Viewport-Größe angepasst, was dazu führte, dass die Seite (Scroll-Position) sprang. Irgendwann im Jahr 2016 hat Chrome daher das gleiche Verhalten wie iOS Safari implementiert.
Was ist, wenn du die html/body-Höhe auf 100 % setzt, aber den Body als Flex-Container mit Spaltenrichtung anzeigen lässt? Das würde es dir ermöglichen, einen Footer mit fester Höhe und einen Hauptbereich zu haben, der den gesamten verfügbaren Platz einnimmt.