Re: [csswg-drafts] [css-values-4] Clarify how and when the initial containing block and visual viewport may deviate (#5777)

> So, let's see if we can address that first, and maybe I can produce an updated article correcting what needs to be corrected and we can go from there.

:+1: 

> Does the ICB change size, and if so, in response to what? I presume it changes size in response to viewport resize (e.g. change from portrait to landscape on mobile, or browser window resize on desktop.) Does it also expand on pinch-zoom on mobile?

On desktop the ICB is very simple; it changes size only when you resize the window. Here, the layout viewport will always be the same size as the ICB. (ICB size doesn't ever change in response to pinch-zoom).

Mobile is where things get complicated.

On mobile, the ICB can change size if the window is resized, via rotation or with the on-screen-keyboard appearing (though I think this varies by browser). It doesn't change size from the URL bar coming in and out.

However, its size can be disconnected from device dimensions using the `<meta name="viewport">` tag. When you specify `width=x` in this tag, you're specifying the size of the ICB. Most mobile-friendly sites specify `width=device-width` which means the ICB will match the device dimensions. In this case, assuming a well-behaved layout (see below for alternatives), the ICB and layout viewport will more or less be the same size (aside from the URL bar behavior).

However, things get extra wonky in the edge cases. Three important points:

 - Authors can specify an exact pixel size in the meta tag - or omit it, in which case I believe most browsers use a default pixel width (Chrome uses `980px`) rather than `device-width`.
 - Authors can also use the tag to set scale limits (though I think Safari now ignores these). Remember that we define the layout viewport to be the size of the visual viewport at minimum scale.
 - By default (and as a limit) the minimum scale is defined such that the visual viewport encloses the content width at minimum scale. That is, so the user can zoom out to see the full content width (but no more).

This means authors can explicitly, and separately, control the size of both the ICB and the layout viewport. Here's an illustrative example:

```html
  <meta name="viewport" content="width=1000,minimum-scale=4">
  <style>
    html {
      width: 250px;
    }
  </style>
  <!-- Assume content doesn't overflow <html> -->
```

Loaded on a mobile device with a 500px screen width we get:

```
ICB = 1000px
Layout Viewport = 125px (since minimum scale is 4, `500px/4 == 125px`)
```

If we remove the `minimum-scale` from the `<meta>` tag we'd get

```
ICB = 1000px
Layout Viewport = 250px (since the computed minimum-scale now comes from content width which so is 2)
```

However, if we now add `<body style="width=2000px">`, the content becomes `2000px` wide so minimum-scale becomes 0.25:

```
ICB = 1000px
Layout Viewport = 2000px
```

All this to the point: the layout viewport and the initial containing block, despite being mostly equivalent in typical, well-behaved cases, can actually vary quite widely. If I remember correctly, `vh` is calculated relative to the ICB (with addition from URL bar height).

-- 
GitHub Notification of comment by bokand
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5777#issuecomment-743260734 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 11 December 2020 15:29:30 UTC