[cssom-view] Expose small/large viewport dimensions of the layout viewport

[ydaniv]

Currently there's no reliable way to get the small/large viewport dimensions.

There are some tricks in the wild for working with these values like inserting an element with something like height: 100svh and reading its height.

It would be handy in some cases to have these values exposed on the VisualViewport interface for easy querying.

I came across this when I was working on a polyfill for ViewTimeline, so I assume there are other common use-cases.

mentioning some folks who might be interested: @bramus @emilio

[bokand]

+1 to the general idea of exposing these values but I'd not that VisualViewport is probably not the right place for these. small/large viewport are properties of the page's layout whereas VisualViewport is not. Perhaps CSS environment variables would be more appropriate?

[bramus]

Imo there should be something like window.viewport – mimicking window.visualViewport but then exposing values of the (layout) viewport. The large and small dimensions could also have a place on there.

Having these large/small viewport values available would help authors to prepare a layout before the virtual keyboard is actually shown. I know this has been a request from the Ionic team, amongst others (the real problem there being that the Virtual Keyboard API does not trigger a beforeGeometryChange event).

On a side note: it could become confusing when there is more than 1 interactive widget: for the Small Viewport, do you consider just one or all interactive widgets expanded? Right now the virtual keyboard is the only interactive widget so it is not much of a problem, but I can imagine some extra top banner injected by the user agent could be a second one over time.

[bokand]

On a side note: it could become confusing when there is more than 1 interactive widget: for the Small Viewport, do you consider just one or all interactive widgets expanded? Right now the virtual keyboard is the only interactive widget so it is not much of a problem, but I can imagine some extra top banner injected by the user agent could be a second one over time.

The small/large viewports are equally affected by the virtual-keyboard/"interactive-widget". It's only "scrolling UI" that insets the small viewport (i.e. mobile URL bar/bottom bars). In those cases, all insetting UI should shrink the smaller viewport (i.e. we inset by the top URL bar and a bottom bar if it exists)

[bramus]

Thanks for correcting me @bokand – looks like I’m gonna need more coffee than usual today 🤦‍♂️. Updated my previous reply to strike out that part.

[ydaniv]

@bramus I guess this issue should've been about exposing these on the layout viewport, and not the visual viewport. If so, we could correct the title and tagging and close as per resolution in #9237

[bramus]

Sure! Something like window.viewport.sizes which has large and small objects. Their type would be a slimmed down version of DOMRectReadOnly (without the x and y)

One thing that I’m now thinking about is the interaction with https://drafts.csswg.org/css-viewport/#interactive-widget-section because when using resizes-content, the viewport’s size – represented by the blue box below – changes when the OSK gets shown.

Would that need an event? Or can we assume authors to read it again when a resize event triggers? I think that latter is OK.

[ydaniv]

Sure! Something like window.viewport.sizes which has large and small objects. Their type would be a slimmed down version of DOMRectReadOnly (without the x and y)

Yeah, I'm fine with that.
Also should link @emilio's comment on #5260 (comment).

Would that need an event? Or can we assume authors to read it again when a resize event triggers? I think that latter is OK.

I think using existing events for resize on window and visualViewport should be fine.

Proposing

Expose a new endpoint for accessing the layout viewport, either window.viewport or window.layoutViewport - TBB.
This endpoint should expose large/small/dynamic as accessors for a DOMRectReadOnly-like objects with width/height/block/iniline properties as doubles.

[bramus]

Proposing

Expose a new endpoint for accessing the layout viewport, either window.viewport or window.layoutViewport - TBB. This endpoint should expose large/small/dynamic as accessors for a DOMRectReadOnly-like objects with width/height/block/iniline properties as doubles.

This should definitely be stored on window.viewport