In november, met de release van Chrome 108, brengt Chrome enkele wijzigingen aan in het gedrag van de Layout Viewport als het schermtoetsenbord (OSK) wordt getoond. Met deze wijziging past Chrome op Android het formaat van het opmaakkijkvenster niet meer aan, maar alleen het formaat van het visuele kijkvenster. Hiermee wordt het gedrag van Chrome op Android gelijkgetrokken met dat van Chrome op iOS en Safari op iOS.
Hieronder vind je meer informatie over wat er gebeurt, waarom Chrome deze wijziging doorvoert en wat je kunt doen om je voor te bereiden.
Het layoutkijkvenster en het visuele kijkvenster
Als je een website bezoekt, zie je niet de hele pagina nadat deze is geladen. In plaats daarvan biedt de browser je een weergavegebied waarin je een deel van de pagina kunt zien. Deze viewport wordt ook wel de indeling-viewport genoemd. Als de content van een pagina te groot wordt, biedt de browser een scrollmechanisme.
Als je elementen positioneert met position: fixed, worden ze ingedeeld op basis van die layout-viewport. Omdat het weergavevenster voor de vormgeving op zijn plaats blijft als je omlaag scrollt op een pagina, blijven elementen die position: fixed gebruiken ook op hun plaats.
position: fixed (blauwe vakken). Van links naar rechts: Safari op iPhone, Chrome op Android en Firefox op Android.
Naast deze viewport voor indeling biedt de browser ook een visuele viewport. Dit geeft het gedeelte van het kijkvenster aan dat op dat moment zichtbaar is. Op zoomniveau 1 is deze visuele viewport even groot als de viewport voor indeling.
Als je inzoomt door te knijpen, verklein je de grootte van de visuele viewport ten opzichte van de opmaakviewport.
Gedrag voor formaataanpassing van kijkvenster
Als je de focus legt op een invoerveld of een ander bewerkbaar gebied, kunnen apparaten (meestal apparaten met een touchscreen) een schermtoetsenbord tonen. Met dit toetsenbord, vaak een virtueel toetsenbord genoemd,kunnen gebruikers content invoeren in het bewerkbare gebied.
Browsers reageren dan op een van de volgende manieren op de verschillende viewports:
- Alleen het formaat van het visuele kijkvenster aanpassen en het opmaakkijkvenster verschuiven.
- Pas het formaat van zowel het visuele kijkvenster als het opmaakkijkvenster aan.
- Pas het formaat van het opmaakkijkvenster of het visuele kijkvenster niet aan en plaats het virtuele toetsenbord als overlay op beide.
Deze 3 gedragingen worden als volgt gevisualiseerd:
Afhankelijk van de browser en het OS dat een bezoeker gebruikt, wordt een van de gedragingen gebruikt, buiten uw controle.
De verschillende gedragingen voor formaat aanpassen in kaart brengen
In het Viewport Investigation Effort-deel van Interop 2022 zijn verschillende viewport-gerelateerde aspecten onderzocht voor elke belangrijke browser- en OS-combinatie.
Een van de geteste aspecten is het gedrag voor formaat aanpassen als het OSK wordt getoond. Dit heeft geleid tot de volgende classificatie:
Groep één
Browsers die het formaat van het visuele kijkvenster aanpassen, maar het opmaakkijkvenster ongewijzigd laten.
- Safari op iOS
- Safari op iPadOS
- Chrome op ChromeOS
- Chrome op iOS
- Chrome op iPadOS
- Edge op iOS
- Edge op iPadOS
Groep 2
Browsers die het formaat van zowel de visuele viewport als de opmaakviewport aanpassen.
- Chrome op Android
- Firefox op Android
- Edge op Android
- Firefox op iOS
Groep 3
Browsers die het formaat van geen van de viewports aanpassen:
- Standaard geen: In Chrome op Android kun je je aanmelden voor dit gedrag via de VirtualKeyboard API
Bijwerkingen van elk gedrag
Dit verschil in hoe de verschillende viewports worden aangepast als het OSK wordt getoond, leidt tot een niet-interoperabele indeling en formaatgedrag van websites.
In de browsers van groep 1, met het OSK getoond:
- De berekende waarden voor viewport-relatieve eenheden blijven hetzelfde.
- Elementen die zijn ontworpen om de hele visuele ruimte in beslag te nemen, behouden hun grootte.
- Elementen die
position: fixedgebruiken, blijven op hun plaats en kunnen worden verborgen door het schermtoetsenbord.
In de browsers van groep 2, met het OSK getoond:
- De berekende waarden voor viewport-relatieve eenheden worden kleiner.
- Elementen die zijn ontworpen om de hele visuele ruimte in te nemen, worden kleiner.
- Elementen die
position: fixedgebruiken, kunnen ergens anders in de indeling terechtkomen.
position: fixed gebruiken (blauwe vakken). Hier zie je Safari op iOS (links) en Chrome op Android (midden en rechts).
Tenzij u User-Agent-sniffing gebruikt of afhankelijk bent van uitgebreide scripts, kunt u niet weten welk gedrag wordt gebruikt. U kunt het gedrag ook niet wijzigen, omdat dit wordt bepaald door de combinatie van browser en OS die de gebruiker gebruikt.
Het standaardgedrag wijzigen in Chrome 108
Vanaf Chrome 108 past Chrome op Android het gedrag voor formaataanpassing van het kijkvenster aan, zodat het formaat van het opmaakkijkvenster niet meer wordt aangepast als het schermtoetsenbord wordt getoond.
Hierdoor komt het gedrag van Chrome op Android overeen met dat van Chrome op iOS, iPadOS, Windows en CrOS, Safari op iOS en iPadOS, en Edge op iOS, iPadOS en Windows.
Dankzij deze wijziging weten auteurs welk gedrag wordt gebruikt, ongeacht het OS waarop Chrome wordt uitgevoerd. Bovendien maakt het stabiele viewport-relatieve eenheden mogelijk: het tonen of verbergen van het schermtoetsenbord heeft geen invloed op deze eenheden.
Toestemming geven voor ander gedrag
Als je wilt dat je website het gedrag voor formaat aanpassen van vóór versie 108 gebruikt, maak je dan geen zorgen. In Chrome 108 wordt ook een extensie voor de viewport-metatag geleverd.
Via de interactive-widget-sleutel kun je Chrome laten weten welk gedrag voor formaat aanpassen je wilt.
Geaccepteerde waarden voor interactive-widget zijn:
resizes-visual: Pas alleen het formaat van de visuele viewport aan, niet dat van de lay-outviewport.resizes-content: Pas het formaat van zowel de visuele viewport als de lay-outviewport aan.overlays-content: Pas het formaat van geen enkele viewport aan.
Als je je weer wilt aanmelden voor het 'oude' Chrome op Android-gedrag, stel je de viewport-metatag in op:
<meta name="viewport" content="width=device-width, initial-scale=1.0, interactive-widget=r>esizes-content"
Als je interactive-widget niet opneemt in de viewport-metatag, gebruikt Chrome het standaardgedrag, namelijk resizes-visual.
Gevisualiseerd hebben de instellingen dit effect op de verschillende weergavegebieden:
resizes-visual, resizes-content en overlays-content.
Je kunt het effect van elke waarde in je browser uitproberen op deze demowebsite.
Testen en feedback
We verwachten enkele kleine verschillen met bestaande sites, maar verwachten dat deze niet blokkerend zijn, omdat Chrome 108 op Android zich nu vergelijkbaar gedraagt als Safari op iOS. Websites die goed werken in Safari op iOS, zouden dus ook goed moeten werken in Chrome 108 op Android.
We raden website-auteurs wel aan hun websites actief te testen in Chrome 108, dat vanaf 27 oktober 2022 in bèta is. Let vooral op elementen die position: fixed gebruiken en/of afhankelijk zijn van Viewport-relative units.
Je kunt feedback melden op crbug.com. Vermeld 'on-screen keyboard' (schermtoetsenbord) in de titel van de melding.