> If you have wide non-text content, for example an img, then the page will not necessarily appear at scale 1. Hmm, interesting. Thanks for the correction; I c

> If you have wide non-text content, for example an img, then the page will not necessarily appear at scale 1. Hmm, interesting. Thanks for the correction; I confirm this in Chromium’s responsive design mode. Also that (as expected) if you’ve got suitable `max-width: 100%; height: auto` incantations so that it doesn’t actually overflow, this doesn’t apply, and you stay with an initial scale of 1. Frankly, I think that removing initial-scale=1 while developing might be a good thing, since it’ll make overflow more obvious, but I now have a clearer understanding of initial-scale’s purpose and default value. I suppose that means that it’s probably still desirable in general, as most causes of overflow are probably better handled by inducing scrolling rather than scaling the whole document down. Need to file an issue to fix https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... which claims the default is 1, then. Going to add a blog post about this to my TODO list as well, since I had erroneously thought it was solely about that Safari orientation change bug, and have mentioned that belief a few times here on HN and probably misled others thereby. (Found some potentially relevant spec, too: https://www.w3.org/TR/css-device-adapt/#handling-auto-zoom https://www.w3.org/TR/css-device-adapt/#handling-auto-zoom, though I’m not sure quite what the situation is, HTML Standard seems to cite that spec but a csswg draft, and that link’s a 404, and the @viewport stuff hasn’t ever been implemented and has been retired <https://github.com/w3c/csswg-drafts/issues/4766 https://github.com/w3c/csswg-drafts/issues/4766>, so I’m not sure if there’s actually any nominally-active spec for meta viewport at present.)