Meta Tags and Viewport

## Why phones have two viewports When smartphones shipped, essentially every site on the web assumed a desktop-sized window. If a phone had laid those pages out at its real width — 320 to 430 CSS pixels — fixed 960-pixel layouts would have overflowed and broken. So mobile browsers introduced a split: - The **layout viewport** is the rectangle the page is laid out into. It is what percentage widths resolve against, what `vw` units measure, and what width-based media queries test. - The **visual viewport** is the part of that layout the user is currently looking at. Pinch-zooming and scrolling move the visual viewport around inside the layout viewport; they do not re-run layout. By default a phone browser sets the layout viewport to a wide value — roughly 980 CSS pixels, with the exact number varying by browser — lays the page out there, then scales the rendering down so the whole thing fits the screen. A legacy desktop site therefore appears intact but tiny, and the user zooms in to read it. That default is a compatibility hack for the pre-mobile web, and it is still the behaviour you get today when the tag is missing. ## What the tag actually does The viewport meta tag opts a page out of that hack: ```html <meta name="viewport" content="width=device-width, initial-scale=1"> ``` The `content` attribute is a comma-separated list of key/value pairs: - `width=device-width` sets the layout viewport width to the device's width in CSS pixels. You can also give a fixed number (`width=480`), but that re-creates the original problem on a different device. - `initial-scale=1` sets the zoom level at which the page is first displayed: 1 means 1 CSS pixel maps to 1 device-independent pixel, i.e. no initial zoom. It also matters historically: on older iOS, a page with only `width=device-width` could fail to re-lay-out correctly after rotation, and pairing it with `initial-scale=1` was the standard fix. The pair is now the boilerplate. - `minimum-scale` / `maximum-scale` bound how far the user may zoom out or in. - `user-scalable=yes|no` says whether the user may zoom at all. - `viewport-fit=cover` lets the page paint into the display cutout area on notched devices instead of being letterboxed into the safe area, and is what enables the `env(safe-area-inset-*)` values so you can pad content back out of the notch. Note that `width` and `initial-scale` interact: if you give only `initial-scale=1`, the browser derives a layout width from the scale, which on most devices ends up equal to `device-width` anyway. Specifying both is the unambiguous form. ## Why media queries "stop working" This is the interview payoff. A width media query is evaluated against the layout viewport, not against the physical screen and not against the device's pixel count. Without the tag the layout viewport is ~980 CSS pixels on every phone, so: ```css @media (max-width: 600px) { /* never matches on a phone without the viewport tag */ } ``` is correctly reporting that the viewport is wider than 600 pixels. Nothing is wrong with the CSS; the browser was told nothing about the device, so it used the legacy default. Add the tag and the same query matches immediately. A related confusion is device pixel ratio. A phone advertising a 1170-pixel-wide screen is usually 390 CSS pixels wide at a ratio of 3. Media queries work in CSS pixels, so `max-width: 600px` is about the CSS width, never the hardware pixel count. ## What the tag is not - It is not responsiveness. It does not resize images, reflow columns, or scale text. It only fixes the width your stylesheet is measured against; the layout work is still yours. - It is not a desktop concern. Desktop browsers lay out into the window and ignore the tag, which is why a bug caused by its absence is invisible until you open the site on a real phone or in device emulation. - It is not a place for clever values. `width=1024` or a hard `maximum-scale` pins users to your assumptions; `width=device-width, initial-scale=1` is the answer in nearly every real project. ## How it fails in practice The tag lives in `<head>` and is read by the parser as the document is built. Typical production bugs are boring: the tag was never added to a hand-written template, a page type renders its own head and omits it, or an email/webview wrapper strips it. The symptom is always the same — the page is legible but shrunken on mobile and every breakpoint behaves as if the browser were a desktop.