A few things, yeah. Sticky headers, in some browsers position:sticky isn’t quite so well supported. Then there’s the odd viewport sizing in iOS that was a little bit of an annoyance. I kind of read the whole, long bug tracker thread in the WebKit forum about why they decided to size the viewport units the way they did. And it makes sense, I understand the logic, but we did have to figure out a few workarounds for a couple of our screens. On iOS, as I’m sure you know, as you’re scrolling the address bar will collapse. The viewport size is calculated based on the collapsed size of the header. If you want, say a full page screen, that fills the screen but no more, then you can’t use viewport units. There is some webkit-specific stuff baked into Safari that we ended up using that will avoid that problem. But that was one of our initial stumbling blocks when we were trying to have a full-screen, non-scrollable view in mobile Safari.
We use -webkit-fill-available to handle that. That was the primary fix we found for the 100vh size issue in mobile Safari.
Does Chrome do it differently?
Honestly I can’t remember if we had the same issue on Chrome for mobile. I know on iOS it uses the internal WebKit, so it probably just worked from that same property.
You mentioned position:sticky, what did you do?
The problem was actually in Edge. We had a stack of fullscreen videos that would stick as you scroll. On Edge there was a crazy amount of flickering as we were scrolling. We actually never quite fully resolved that. We made it a little bit better by drawing the videos, the background videos, to a canvas element instead of playing the video directly, which helped a little bit. But we honestly, it was something we just didn’t have the time to figure out, and given the percentage of people who use Edge, we just decided it was acceptable.
Other scrolling issues?
Made with FlippingBook - professional solution for displaying marketing and sales documents online