Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values-4] initial work on vhc unit proposal text. Resolves #4329 #5108

Closed
wants to merge 1 commit into from

Conversation

frehner
Copy link

@frehner frehner commented May 24, 2020

Resolves #4329

I don't think vhc is (or should be) the final unit's name; however, I did want to start working on the text for this new unit, and then we can swap out once that's decided.

This is my first time proposing changes to the spec, so I probably did something wrong. Let me know and I'll fix it :)

I don't think `vhc` is (or should be) the final unit's name; however, I did want to start working on the text for this new unit, and then we can swap out the name at a later time.
@astearns
Copy link
Member

@tabatkins @fantasai

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

@frehner
Copy link
Author

frehner commented May 26, 2020

@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

@frivoal frivoal added the css-values-4 Current Work label Jul 14, 2020
@frehner
Copy link
Author

frehner commented Sep 14, 2020

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?)

@brunoais
Copy link

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

@johannesodland
Copy link

johannesodland commented Sep 28, 2020

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.

@brunoais
Copy link

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

Base automatically changed from master to main February 2, 2021 19:45
@johannesodland
Copy link

johannesodland commented Mar 17, 2021

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

visual viewport vs vu

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?

@brunoais
Copy link

@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.

@johannesodland
Copy link

@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.

@frehner
Copy link
Author

frehner commented Mar 17, 2021

@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.

@brunoais
Copy link

brunoais commented Mar 17, 2021

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

@frehner
Copy link
Author

frehner commented Mar 17, 2021

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.

@johannesodland
Copy link

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

@frehner
Copy link
Author

frehner commented Mar 20, 2021

@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.

@johannesodland
Copy link

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 👍🏼

@fantasai
Copy link
Collaborator

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

@fantasai fantasai closed this Jun 18, 2021
@frehner frehner deleted the patch-1 branch June 18, 2021 02:12
@frehner
Copy link
Author

frehner commented Jun 18, 2021

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. 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-values-4 Current Work
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[css-values-4] Add vhc value
6 participants