Skip to content

[css-values-4] viewport units vs initial containing block #6453

Closed

Description

@fantasai

How does (or doesn't) the initial containing block correspond to the various viewport units? Are there any units for which html { height: 100%; } = html { height: 100*vh; } ?

Activity

  1. gsnedders commented on Nov 29, 2021

    @gsnedders
    Member

    is this not a dupe of #5218 and #5777?

  2. flackr commented on Jun 20, 2022

    @flackr
    Contributor

    On experimentation it looks like html { height: 100%; } = html { height: 100svh; }. Demo at https://flackr.github.io/web-demos/viewport/units/ showing each of the equivalent heights.

  3. bramus commented on Jun 21, 2022

    @bramus
    Contributor

    Notes from talking to @bokand about this some time last week

    Visualisation:

    • ICB = html { height: 100%; width: 100%; }
    • LVP = #fixed { position: absolute; height: 100%; width: 100%; }

    The units can be derived as such:

    • svh unit = height of ICB
    • lvh unit = height of ICB + height of extra bars (top/bottom bar)
    • vh unit = free for interpretation as per spec, yet all browsers seem to have settled on setting it equal to lvh
  4. tabatkins commented on Oct 27, 2023

    @tabatkins
    Member

    Quick test to show off the viewport -> unit correspondence: https://xanthir.com/etc/tests/viewports/

    <!DOCTYPE html>
    <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
    <style>
    html { height: 100%; width: 15%; margin: 0; padding: 0; background: white; }
    body { margin: 0; padding: 0; }
    div { top: 0; }
    #abs { position: absolute; height: 100%; width: 15%; left: 15%; background: #0f03;}
    #fixed { position: fixed; height: 100%; width: 15%; left: 30%; background: #00f3;}
    #svh { position: absolute; height: 100svh; width: 15%; left: 45%; background: #ff03; }
    #dvh { position: absolute; height: 100dvh; width: 15%; left: 60%; background: #f0f3; }
    #lvh { position: absolute; height: 100lvh; width: 15%; left: 75%; background: #0ff3; }
    * { box-sizing: border-box; }
    html, div[id] { border: thick dotted; }
    div { writing-mode: vertical-rl; writing-mode: sideways-rl; }
    </style>
    <div id=abs>abspos, height 100%</div>
    <div id=fixed>fixpos, height 100%</div>
    <div id=svh>abspos, height 100svh</div>
    <div id=dvh>abspos, height 100dvh</div>
    <div id=lvh>abspos, height 100lvh</div>
    <div>&lt;html>, height 100% (ICB)</div>
    <br><br>
    foo<br>
    foo<br>
    ...more foos truncated...

    Blink, WebKit, and Gecko have consistent behavior:

    • ICB is the small viewport size
    • abspos containing block is the small viewport size
    • fixpos containing block is the layout viewport (aka dynamic viewport size)
    • small/dynamic/viewport all work as expected - large overflows the viewport at first, but is the size of the viewport after the URL bar hides. Dynamic matches svh until the URL bar hides, at which point it snaps to matching lvh.

    Note: Firefox on iOS is a little broken; it treats all the viewport units as svh, never changing them as the URL bar hides. It does still resize the fixpos containing block, tho.

    Proposal: Spec the current interoperable behavior: that the ICB matches the small viewport, but the fixedpos containing block matches the dynamic viewport.

  5. tabatkins commented on Oct 27, 2023

    @tabatkins
    Member

    (This should close #5218, #8410)

  6. css-meeting-bot commented on Nov 1, 2023

    @css-meeting-bot
    Member

    The CSS Working Group just discussed [css-values-4] viewport units vs initial containing block, and agreed to the following:

    • RESOLVED: We define relationship between ICB, abspos, and fixedpos and viewport size as detailed in the comment
    The full IRC log of that discussion <dael> TabAtkins: There was some certain screen sized things related to ach other. ICB, viewport units, and fixedpos cb.
    <dael> TabAtkins: Appears there is almost perfect consistency. There wasn't a few years back, but have converged with one exception.
    <dael> TabAtkins: Suggest we spec. ICB is small viewport size. abspos cb that you get if you have abspos relative to no element is also small viewport size. fixedpos if the layout viewport which is the dynamic viewport size
    <dael> TabAtkins: That's the proposal. ICB is small viewport. fixedpos matches dynamic viewport
    <dael> astearns: How is FF on iOS differing from Safari when they use same engine?
    <dael> TabAtkins: That's a great question and we don't know, but it was definitely doing that. We have no idea. But browsers showed different behavior for this test case.
    <smfr_> There is some WKWebView and UIScrollView inset stuff that can affect this behavior, and they are controllable by the app
    <dael> astearns: Okay defining all these relationships. I assume we should have WPTs as well
    <dael> TabAtkins: Yep. We'll verify that there is
    <dael> astearns: And smfr_ in chat gave us a possibility for why the difference
    <dael> TabAtkins: Yes, I thought the web rect might be effecting it.
    <TabAtkins> s/the web/stuff outside the web/
    <smfr_> no concerns
    <dael> astearns: Prop: We deinfe relationship between ICB, abspos, and fixedpos and viewport size as detailed in the comment
    <dael> astearns: Obj?
    <dael> RESOLVED: We define relationship between ICB, abspos, and fixedpos and viewport size as detailed in the comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions