@tabatkins @fantasai

@frehner you should have gotten an email from someone at the W3C about intellectual property commitments

@frehner you should have gotten an email from someone at the W3C about intellectual property commitments

I haven't received anything yet as far as I can tell. I also just checked my spam folder just in case

I created and linked my w3c account to my github account. However, I'm not entirely sure if I need to do more (e.g. join the csswg? and can I do that if I'm not part of a sponsor company?)

For the name, I like the vvh @bmakuh suggests.

For the name, I like the vvh @bmakuh suggests.

Won't vvh be confusing, if it refers to the visual viewport?
The visual viewport is what's visible on the screen with or without chrome and even after pinch-zoom.
The new viewport unit refers 1% of the screen height "with chrome".

When chrome is hidden, the visual viewport will refer to the screen with chrome hidden, but vhc will still refer to 1% of the height with chrome.
When the user pinch-zooms the visual viewport will refer to the area that is visible on the screen. vhc will still refer to 1% of the height with chrome.

I don't understand what you are mentioning about vvh as Visual Viewport Height being confusing.

I don't understand what you are mentioning about vvh as Visual Viewport Height being confusing.

The draft is clarifying that 1 vh equals 1% of the height of the initial containing block with the user agent chrome at its smallest size. 1 vhc is defined as 1% of the height of the initial containing block with the user agent chrome at its largest size.

Both values are defined in terms of the layout / fixed viewport.

Above there are three screenshots from a simulated iphone.

Left: UA Chrome at smallest size
On the left the viewport has user agent chrome at its smallest size.
Here the visual viewport height is equal to 100vh (749px)

Middle: UA Chrome at largest size
In the middle the viewport has user agent chrome at its largest size.
Here the visual viewport height is equal to 100vhc (635px)

Right: With scale
On the right the viewport has been scaled. (The viewport can be scaled either through pinch zooming, or by focusing on an input element.) The visual viewport height is now 437px, and not equal to 100vh nor 100vhc.

The height of the visual viewport will some times be equal 100vh and other times be equal to 100vhc. When scaled it will be a different value all together. Naming one of the units after the visual viewport is confusing, as the visual viewport changes and will equal either of the units at different states.

Maybe @bokand can weigh in here?

@johannesodland That doesn't seem to be my interpretation of how vhc should work.
In my interpretation, vhc will adjust including and between the 749px and 635px depending on the browser's actual visual viewport size. It's those and everything in between so it also reflects when the chrome is, for example, only half size extended.

Is our conflicting interpretations the confusion part? Because if what happens is actually your interpretation, this new property being suggested is, for the most part, barely useful at all.

@brunoais I think our interpretations are definitely different.

This PR specs a vhc unit as folows:

vhc unit
When user agent chrome does not change size, it is equal to 1% of the height of the initial containing block.
When user agent chrome does change size, it is equal to 1% of the height of the initial containing block with the user agent chrome at its largest size.

As I interpret it it, this viewport unit is defined relative to the ICB and will only change when a window is resized and the ICB changes size. It is stable and does not change when UA chrome changes size. (It will be 635px on the iPhone in my example, as long as the phone is not rotated.)

If the unit changed with the UA chrome we would get all the reflow issues that we had with vh earlier.

Having this unit in addition to vh is very useful, at least for us. It allows us to use css to style content that fits inside the browser chrome without using JS.

Viewport units matching the visual viewport could be useful too as a way to reference the visual viewport API values in CSS, but as I read the original issue and the PR this unit is defined relative to the ICB.

@brunoais I think our interpretations are definitely different.

This PR specs a vhc unit as folows:

vhc unit
When user agent chrome does not change size, it is equal to 1% of the height of the initial containing block.
When user agent chrome does change size, it is equal to 1% of the height of the initial containing block with the user agent chrome at its largest size.

As I interpret it it, this viewport unit is defined relative to the ICB and will only change when a window is resized and the ICB changes size. It is stable and does not change when UA chrome changes size. (It will be 635px on the iPhone in my example, as long as the phone is not rotated.)

If the unit changed with the UA chrome we would get all the reflow issues that we had with vh earlier.

Having this unit in addition to vh is very useful, at least for us. It allows us to use css to style content that fits inside the browser chrome without using JS.

Viewport units matching the visual viewport could be useful too as a way to reference the visual viewport API values in CSS, but as I read the original issue and the PR this unit is defined relative to the ICB.

This is the correct interpretation of the vhc unit. Having a value that changes causes issues with rendering; see the discussion in the issue for details.

Ok. Definitely my bad. Then I guess I will try to come up with another proposal that does as I remembered.

Ok. Definitely my bad. Then I guess I will try to come up with another proposal that does as I remembered.

Sounds great! When you make it, link to it from the original issue if you don’t mind! I would love to follow it.

@frehner CSS Values 4 has logical viewport-percentage lengths vb and vi as well. Should these be considered as well?

@frehner CSS Values 4 has logical viewport-percentage lengths vb and vi as well. Should these be considered as well?

Seems like they should, yes. I'm not sure if here or the related issue would be the place to bring that up with the WG though.

Seems like they should, yes. I'm not sure if here or the related issue would be the place to bring that up with the WG though.

You’re right. I’ll bring it up in th issue 👍🏼

Hi @frehner ! @tabatkins and I committed 0f78ba4 as a replacement of this PR. Not that there was anything specifically wrong with yours, it was a good set of edits! But we needed a lot more detail in the spec, and also a bit of restructuring seemed necessary, so I'm going to close out this PR without accepting. We did add your name to the Acknowledgements section, though, to say thanks for your efforts on this issue. ;) You did a great job of channeling the discussion and helping to make this happen. <3

Hi @frehner ! @tabatkins and I committed 0f78ba4 as a replacement of this PR. Not that there was anything specifically wrong with yours, it was a good set of edits! But we needed a lot more detail in the spec, and also a bit of restructuring seemed necessary, so I'm going to close out this PR without accepting. We did add your name to the Acknowledgements section, though, to say thanks for your efforts on this issue. ;) You did a great job of channeling the discussion and helping to make this happen. <3

Thank you both so much; I’m excited to see progress, and honestly it it makes me a little giddy to see my name in there as well. 😃