(CSS WG Issue: w3c/csswg-drafts#7475)
There is an issue is about position: fixed and how it works, specifically about to what a PosFixed element is laid out against.
Right now, browsers use the Layout Viewport as the Containing Block for PosFixed elements.
Authors use this to position something at the bottom of the page, such as a footer bar on a shopping site or a floating action button.
On mobile this becomes a bit of a problem when the Virtual Keyboard is revealed. Right now, all mobile browsers – except firefox – do not resize the layout viewport when the VK gets shown. Instead, they resize the Visual Viewport (and often shift the Layout Viewport along with that up a bit to keep stuff in view).
Because of that, the PosFixed bottom toolbar or the FAB buttons can get obscured by the VK, which authors might not want.
In the issue, Rob has laid out these behaviors goes over several options. To summarize, the proposal is option 5 as listed in the issue, where the virtual keyboard would be taken into account when doing position: fixed – This essentially creates a “Pos Fixed Viewport” and mimics native app behavior.
We discussed this at the previous F2F in NYC, but unfortunately folks from WebKit were not present at the time. What we discussed then, is wether or not this should be done so by default or not. We kinda were in the direction that it should be an opt-in for authors, maybe through a new property that can cascade independently of position and maybe making position a longhand in that case. This rhymes with what we saw earlier this morning, with the anchoring proposal Jen presented. During the previous F2F we requested more feedback from other vendors, but this seems to have slipped off the radar. I would love to get feedback today, now that we are all in the same room.
To already tackle a question or concern that will most likely be raised: pinch-zoom has no effect on the “Pos Fixed Viewport”. Its size is essentially the “Visual Viewport Before Zoom”. So there’s no layout trashing while pinch-zooming.