Sorry for the toddler-level blog post title there, but I’m about to document a super dumb “bug” that’s been an issue for us since the beginning of time.
If you put an
<iframe> on a website and look at it in a web browser on iOS, the height of that iframe will be the height of the content inside that iframe.
Tell it to be a certain height with CSS? Too bad, doesn’t work. Tell it be a certain height with it’s
height attribute? Too bad, doesn’t work.
That’s actually kinda useful sometimes. For example, say you want to embed a form on a website with an iframe. You don’t know the height of the form, and it might change if, say, there are validation errors. It would be cool if the iframe just matched the height of the document inside.
That’s actually quite difficult to pull off on desktop browsers. The best solutions involve
postMessage() and sending the height back to the parent page for it to adjust itself.
But it’s quite annoying when you really would like to set that
height on the iframe and let it scroll as necessary.
The symptoms here on CodePen? There are several.
Imagine you have a Pen with a lot of stuff in it so it’s super tall and you have to scroll vertically. As we just learned, the iframe in which we show you that Pen will now be super tall on iOS. SoR30;
vh(and related) units in CSS will be unpredictably weirdly huge
- The Pen will trigger no
scrollevents, because, well, it never scrolls (only the parent elements does, which is there just to allow for smooth scrolling at all)
position: fixedelements will appear broken (they are just fixed to a giant document that never scrolls).
The solution on CodePen, if this is causing problems for you, is to use Debug View which doesn’t have an iframe so things should work fine.
It would be cool if iOS could just fix this. Personally, I’d be at least slightly more satisfied to know why it is this way.