[css-values-4] Should dv* account for overflow: auto scrollbars dynamically?
#10059
Comments
The problem with that idea: The new viewport units were introduced to solve the problem of Regarding 
So maybe auto scrollbars could become the main use-case for them. |
|
The Large and Small units should act identically save for the hideable UI. And we defined dynamic to always be between those two, so I think it would be weird to have that sometimes not be the case now. |
|
I'm in favor of it. I initially designed for them to be taken into account and I still support the position that they are supposed to be taken into account. @simevidas For the 1st use-case there, the 100% doesn't work at all. You still need to put the tag as child of If the behavior is not the expected one, it's not the unit's fault but its implementation. E.g. (which seems to be the complaint in the link of that text) If swiping seemingly doesn't do anything until the collapsible overlay finishes moving, then it's the browsers' fault and not the unit's fault. It's true that it's fulfilling the unit but it's the browser's responsibility to make the behavior feel right. The main idea is also for the addressbar to retract and when that happens, things either get larger or there's more content visible. See also section "Current Workarounds" here about what's also trying to solve with this. I haven't done much public work but I already made some PoC for my company which previously the solution was mostly a hack and with the use of dvh. One example is the dialogue always looks "good" (from the designers POV) and centered on screen, taking most but not all height and width, matching the design documents from the designers and without the need for hacky javascript (the scrollbars are still a small issue, though) |
|
@brunoais I don’t understand your comment, but if there exists a web page that demonstrates a valid use-case for |
|
I'm really bad at creating problems so I'll try this weekend to create a simplified repro without breaking NDA. |
|
It's kinda hard to replicate the issue I solved but here's something close-ish: The thing I had to deal with was much more complex but this is one example. I had quite a struggle with the android emulator because I don't have any of the test phones with me now and desktop browsers don't suffer from this. In the first one, the idea is to demonstrate an overlay. Something that, I accept, will soon be replaced with the dialog element. However, it still shows it well-enough. The second one is another situation I encountered. There's a map to be shown with custom pins and it's intended to occupy as much of the screen as viable without being overwhelming (the |
|
@brunoais Have you tried using |
|
Yes. In the emulator with firefox browser, it didn't work. 100% was doing the same as 100v |
|
Example 1: https://output.jsbin.com/liwoyix/quiet I tested in mobile browsers. The only difference is vertical margins. Specifically, |
Technically speaking you could then also say that But if you were to change that one, then you’d effectively unlink |
In #6026 we resolved to restore the rule that made viewport units account for
overflow: scroll. But this is only part of the equation: it doesn't handleoverflow: auto. The restriction was put in originally because cycling computed style after layout was complicated.But since the
dv*units are already dynamic, and are relatively new so have fewer compat restrictions, should they be made to dynamically account for scrollbars?If so, should we adjust the
sv*units also?The text was updated successfully, but these errors were encountered: