4 ms·

I would add this: <meta name="viewport" content="width=device-width, initial-scale=1"> All you need is initial-scale=1, not width=device-width, which is red

by lapcat 25d ago

I would add this: <meta name="viewport" content="width=device-width, initial-scale=1"> All you need is initial-scale=1, not width=device-width, which is redundant. "You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, Safari assumes the width is device-width in portrait and device-height in landscape orientation." https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html#//apple_ref/doc/uid/TP40006509-SW26 https://developer.apple.com/library/archive/documentation/Ap... I've confirmed the behavior in testing.

netol 25d ago
This may be Safari-specific? Google recommends setting both: https://developer.chrome.com/docs/lighthouse/best-practices/viewport https://developer.chrome.com/docs/lighthouse/best-practices/...
- OuterVale 25d ago
  You don't need both, but you should have the width set. From that page: > A page fails the audit unless all of these conditions are met: > - The document's <head> contains a <meta name="viewport"> tag. > - The viewport meta tag contains a content attribute. > - The content attribute's value includes the text width=. I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. https://vale.rocks/micros/20260902-1350 https://vale.rocks/micros/20260902-1350
  - lapcat 25d ago
    > I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. This is incorrect. Try adding an <img> that's wider than the device width. Then the whole page gets zoomed and the text unreadably small.
    - OuterVale 25d ago
      The same will happen regardless in the case of content extending beyond the width of the viewport. With `initial-scale=1` it'll be a horizontal overflow, without it'll zoom out. I argue that the latter is preferable (https://vale.rocks/micros/20260908-1315 https://vale.rocks/micros/20260908-1315) but either way should never reach users due to the usability fails and major accessibility issues.
      - lapcat 25d ago
        > I argue that the latter is preferable I disagree vehemently. I couldn't disagree more. The text has to be readable. If you force the reader to zoom in order to read the text, your website is fundamentally broken. Moreover, neither of these considerations apply to images: "you risk having content off-screen which cannot be focused by a keyboard" "A user is extremely unlikely to think to scroll horizontally to see the rest of a document" "There is even great president for it with documents on the web" Typo: precedent. > either way should never reach users This seems practically unavoidable with images, especially screenshots for example. Device widths vary, image widths vary. There is no magical image width that fits every device width, unless the image is very narrow. Moreover, I try to avoid JavaScript altogether when possible, so I don't want custom JS image viewers all over the place.
      - chrismorgan 24d ago
        When you brought these arguments up on Lobsters <https://lobste.rs/c/dsm1up https://lobste.rs/c/dsm1up> I said it wasn’t cut and dried but that my general feeling was of disagreeing with you. I’ve thought about it more since then, and firmed my position up: you should make sure that the presence of initial-scale=1 won’t affect anything (we agree on this point), but that if you make a mistake in this area, it’s much better to have it than not to (we disagree on this part). Of your five points: Your first point is correct. It could be reasonable to omit initial-scale=1 during development, or have something that complains on width overflow. Your second is unavoidable: omitting initial-scale introduces a worse failure (excessively small text). Your third I disagree with: when overflow occurs it will almost always be obvious that you could scroll, because you’ll have text or image that runs to the inline-end edge of the viewport rather than being contained by a page margin as is universally practised. Your fourth isn’t useful—by that argument all documents should be zoomed out until the entire thing fits on screen; but we don’t do that in general because having to manage the zoom to get a useful result is unpleasant, yet that’s what you’re advocating for. Your fifth is irrelevant, I think entirely unrelated to initial-scale.
phil-pickering 25d ago
The latest MDN recommendation is to use only width=device-width, with initial-scale being mostly redundant. Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#viewport_width_and_screen_width https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- lapcat 25d ago
  I've just learned that initial-scale was removed from the MDN recommendation only a few days ago... by the submitted article author! https://github.com/mdn/content/pull/45479 https://github.com/mdn/content/pull/45479
  - chrismorgan 24d ago
    Which was premature because most people have missed that initial-scale doesn’t actually default to 1: https://github.com/mdn/content/issues/45570 https://github.com/mdn/content/issues/45570
deleted 24d ago
[deleted]

by lapcat 25d ago

netol 25d ago

This may be Safari-specific? Google recommends setting both: https://developer.chrome.com/docs/lighthouse/best-practices/viewport https://developer.chrome.com/docs/lighthouse/best-practices/...

OuterVale 25d ago
You don't need both, but you should have the width set. From that page: > A page fails the audit unless all of these conditions are met: > - The document's <head> contains a <meta name="viewport"> tag. > - The viewport meta tag contains a content attribute. > - The content attribute's value includes the text width=. I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. https://vale.rocks/micros/20260902-1350 https://vale.rocks/micros/20260902-1350
- lapcat 25d ago
  > I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. This is incorrect. Try adding an <img> that's wider than the device width. Then the whole page gets zoomed and the text unreadably small.
  - OuterVale 25d ago
    The same will happen regardless in the case of content extending beyond the width of the viewport. With `initial-scale=1` it'll be a horizontal overflow, without it'll zoom out. I argue that the latter is preferable (https://vale.rocks/micros/20260908-1315 https://vale.rocks/micros/20260908-1315) but either way should never reach users due to the usability fails and major accessibility issues.
    - lapcat 25d ago
      > I argue that the latter is preferable I disagree vehemently. I couldn't disagree more. The text has to be readable. If you force the reader to zoom in order to read the text, your website is fundamentally broken. Moreover, neither of these considerations apply to images: "you risk having content off-screen which cannot be focused by a keyboard" "A user is extremely unlikely to think to scroll horizontally to see the rest of a document" "There is even great president for it with documents on the web" Typo: precedent. > either way should never reach users This seems practically unavoidable with images, especially screenshots for example. Device widths vary, image widths vary. There is no magical image width that fits every device width, unless the image is very narrow. Moreover, I try to avoid JavaScript altogether when possible, so I don't want custom JS image viewers all over the place.
    - chrismorgan 24d ago
      When you brought these arguments up on Lobsters <https://lobste.rs/c/dsm1up https://lobste.rs/c/dsm1up> I said it wasn’t cut and dried but that my general feeling was of disagreeing with you. I’ve thought about it more since then, and firmed my position up: you should make sure that the presence of initial-scale=1 won’t affect anything (we agree on this point), but that if you make a mistake in this area, it’s much better to have it than not to (we disagree on this part). Of your five points: Your first point is correct. It could be reasonable to omit initial-scale=1 during development, or have something that complains on width overflow. Your second is unavoidable: omitting initial-scale introduces a worse failure (excessively small text). Your third I disagree with: when overflow occurs it will almost always be obvious that you could scroll, because you’ll have text or image that runs to the inline-end edge of the viewport rather than being contained by a page margin as is universally practised. Your fourth isn’t useful—by that argument all documents should be zoomed out until the entire thing fits on screen; but we don’t do that in general because having to manage the zoom to get a useful result is unpleasant, yet that’s what you’re advocating for. Your fifth is irrelevant, I think entirely unrelated to initial-scale.

phil-pickering 25d ago

The latest MDN recommendation is to use only width=device-width, with initial-scale being mostly redundant. Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#viewport_width_and_screen_width https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

lapcat 25d ago
I've just learned that initial-scale was removed from the MDN recommendation only a few days ago... by the submitted article author! https://github.com/mdn/content/pull/45479 https://github.com/mdn/content/pull/45479
- chrismorgan 24d ago
  Which was premature because most people have missed that initial-scale doesn’t actually default to 1: https://github.com/mdn/content/issues/45570 https://github.com/mdn/content/issues/45570

deleted 24d ago

[deleted]