[css-values-4] viewport units vs initial containing block #6453
Labels
Comments
1 task
|
On experimentation it looks like |
|
Notes from talking to @bokand about this some time last week Visualisation:
The units can be derived as such:
|
|
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><html>, height 100% (ICB)</div>
<br><br>
foo<br>
foo<br>
...more foos truncated...Blink, WebKit, and Gecko have consistent behavior:
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. |
|
The CSS Working Group just discussed
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 |
fantasai
added a commit
that referenced
this issue
Nov 22, 2023
fantasai
added a commit
that referenced
this issue
Nov 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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; }?The text was updated successfully, but these errors were encountered: