[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 https://github.com/w3c/csswg-drafts/issues/5260#issuecomment-2160729990.

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

[css-meeting-bot]

The CSS Working Group just discussed [cssom-view] Expose small/large viewport dimensions of the layout viewport, and agreed to the following:

• RESOLVED: We will expose large/small/dynamic objects representing the layout viewport sizes as accessors with width/height/block/inline properties; details and which object TBD

The full IRC log of that discussion

<fantasai> ydaniv: Already resolved to export viewport object that exposes the properties you can read regarding the layout viewport
<fantasai> ydaniv: on that object proposal is to expose large/small/dynamic accessors
<fantasai> ydaniv: for the widht/height/block/inline properties
<fantasai> ydaniv: so that developers can read those in JS
<fantasai> smfr: Are these live? do they change when you scroll?
<fantasai> fantasai: small/large are static... dynamic changes
<fantasai> smfr: but position changes?
<fantasai> fantasai: only exposes size, not position
<fantasai> smfr: Do we fire an event when dynamic size changes?
<fantasai> ydaniv: I think we already have those
<fantasai> ydaniv: that's the resize event
<fantasai> ydaniv: visual viewport exposes events, no proposal here to make this also an event target
<emilio> q+
<fantasai> smfr: ok
<fantasai> smfr: not sure about the timing of dynamic viewport change and event firing, might not be accurate
<astearns> ack emilio
<fantasai> emilio: This is not ? to the visual viewport resize
<fantasai> s/?/equivalent/
<fantasai> emilio: the visual viewport size, I don't think it changes with the dynamic viewport
<fantasai> emilio: changes when zooming in and out
<fantasai> astearns: so continue discussing, or resolve on adding large/small/dynamic objects to window?
<fantasai> smfr: Slightly concerned about .viewport being confused with visual viewport
<fantasai> emilio: but that's a different discussion
<fantasai> smfr: exposing these somehwere, just unsure where
<emilio> q+
<fantasai> PROPOSED: We will expose large/small/dynamic as accessors with width/height/block/inline properties; TBD on which object
<fantasai> ydaniv: could also resolve on makign this the layout viewport
<fantasai> ydaniv: other than naming, don't think there's an objection
<astearns> ack emilio
<fantasai> PROPOSED: We will expose large/small/dynamic objects representing the layout viewport sizes as accessors with width/height/block/inline properties; TBD on which object
<fantasai> PROPOSED: We will expose large/small/dynamic objects representing the layout viewport sizes as accessors with width/height/block/inline properties; details and which object TBD
<fantasai> RESOLVED: We will expose large/small/dynamic objects representing the layout viewport sizes as accessors with width/height/block/inline properties; details and which object TBD

[bramus]

I wasn’t able to attend the meeting today, so replying here now quoting from the log:

@smfr: Slightly concerned about .viewport being confused with visual viewport

We decided on creating .viewport in https://github.com/w3c/csswg-drafts/issues/9237#issuecomment-2160730855 to prevent exactly that confusion. We have window.viewport for the (layout) viewport and window.visualViewport for the Visual Viewport. Both are two distinct things.

@smfr: exposing these somehwere, just unsure where

These should be exposed on window.viewport because these are specific variants of the layout viewport, not the visual viewport. For the same reason we put .segments also underneath it.

[bramus]

One more:

@smfr: not sure about the timing of dynamic viewport change and event firing, might not be accurate

You could say that dynamic might not be needed here and that only the large and small ones are relevant. Authors can use window.innerHeight to read the actual value (*).

(*) except in WebKit because pinch-zoom incorrectly affects the value … which makes the addition proposed here an extra reason to get this bug fixed.

[ydaniv]

You could say that dynamic might not be needed here and that only the large and small ones are relevant. Authors can use window.innerHeight to read the actual value (*).

(*) except in WebKit because pinch-zoom incorrectly affects the value … which makes the addition proposed here an extra reason to get this bug fixed.

Correct, so perhaps this could be a chance for interop?

[smfr]

I am OK with exposing these on window.viewport given the info above.

[bramus]

Correct, so perhaps this could be a chance for interop?

I suggested it here: https://github.com/web-platform-tests/interop/issues/870

[bramus]

I am OK with exposing these on window.viewport given the info above.

PROPOSED ASYNC RESOLUTION: Expose these objects on window.viewport.

/ping @astearns

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Expose the small/large layout viewport dimensions on window.viewport

[astearns]

RESOLVED: Expose the small/large layout viewport dimensions on window.viewport