Meeting 2 (2022-08-10)

[bramus]

In our first meeting we brainstormed a list of issues which we need to discuss further, in order to get a prioritized list out of that.

Furthermore I’ve been digging into the behavior of the new Viewport(-relative) Units and would like to discuss the plans we have for Chrome in order to achieve (more) interop regarding this.

I’m currently not 100% sure who is interested in joining this discussion, so I’m just going to namedrop here. Please reply wether you are interested in joining this interop research effort and your timezone/availability.

• Google: @rachelandrew @skobes @foolip @bramus
• Mozilla: @emilio @hiikezoe @theres-waldo
• Microsoft: @kypflug
• Apple: @karlcow @jensimmons @gsnedders
• Samsung: @AdaRoseCannon

The goal right now is to have 1 meeting per month, occasionally 2. If you are not interested in joining or can’t join this effort, please forward this within your organisation so that it reaches someone who can join.

[AdaRoseCannon]

I'm interested but not going to be at Samsung too much longer. I will try to get one of my colleagues to participate.

[emilio]

I'm interested, mostly in CEST timezone. I prefer evening to early morning meetings, but can do either.

[skobes-chromium]

I'm interested as well (EST).

…

On Wed, Jul 13, 2022 at 2:02 PM Emilio Cobos Álvarez < ***@***.***> wrote: I'm interested, mostly in CEST timezone. I prefer evening to early morning meetings, but can do either. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7YMN6GO7UPBCHA2NTTES3VT4ADFANCNFSM53PK6K2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jensimmons]

Yes, count me in. I'm in NYC (ET).

[dlibby-]

I'm interested on behalf of Microsoft. I'm in HST time zone and try to keep to ~PST hours, but I do have some flexibility.

[dcrousso]

i could join (on behalf of Apple) from MST if it's not in the morning :)

[bramus]

Looking at the different timezones, I see this overlap:

UTC	CET	US/Eastern	US/Mountain	US/Pacific
15:00:00 +00:00	17:00:00 +02:00	11:00:00 -04:00	09:00:00 -06:00	08:00:00 -07:00
16:00:00 +00:00	18:00:00 +02:00	12:00:00 -04:00	10:00:00 -06:00	09:00:00 -07:00
17:00:00 +00:00	19:00:00 +02:00	13:00:00 -04:00	11:00:00 -06:00	10:00:00 -07:00
18:00:00 +00:00	20:00:00 +02:00	14:00:00 -04:00	12:00:00 -06:00	11:00:00 -07:00
19:00:00 +00:00	21:00:00 +02:00	15:00:00 -04:00	13:00:00 -06:00	12:00:00 -07:00
20:00:00 +00:00	22:00:00 +02:00	16:00:00 -04:00	14:00:00 -06:00	13:00:00 -07:00
21:00:00 +00:00	23:00:00 +02:00	17:00:00 -04:00	15:00:00 -06:00	14:00:00 -07:00

Given that the CET folks – Emilio and me - can work evenings, I suggest 6PM or 7PM UTC (marked in bold, above).

I will send out invitations for dates in the first and second week of August. Whichever of those two dates has the most attendees will be picked.

[bramus]

Meeting confirmed for Wednesday August 10 at 6PM UTC. Agenda will follow.

[gsnedders]

(Also, to be clear, given the above times: that's UTC, not Europe/London, given Europe/London is in summer time and currently UTC +01:00, thus 7pm Europe/London for anyone in Europe trying to calculate an offset from that.)

[bramus]

Reminder that the meeting is tomorrow (~today depending on your timezone). The invite contains a Google Meet link for you to join.

We’ll start with a round of introductions and take it from there. I have prepared (~ am finishing) a bunch of demos/testpages to spark the discussion so that we can, eventually, determine the contents of this investigation effort.

[bramus]

Today we had our second meeting. Attendees: @skobes (Google), @emilio (Mozilla), @dlibby- (Microsoft), @dcrousso (Apple), and @bramus (Google).

• Round of introductions
• @bramus shared a collection of test pages he created, detailing what each does
  • Initial Containing Block (ICB)
  • Layout Viewport
  • Visual Viewport
  • Virtual Keyboard API
  • Viewport Units + window.innerHeight
  • Viewport Units + -webkit-fill-available by @smfr
    • @dcrousso suggested replacing it by https://devinrousso.com/demo/WebKit/css/viewport-units.html, as it also exposes viewport units.
  • ICB + Fixed Viewport + Visual Viewport + Event Debugger
  • (Some more pages to be added later)
• @bramus has been compiling a sheet with findings (still to be made public) that document how each browser alters (or does not alter) certain aspects in certain scenario:
  • Watched aspects
    • Dynamic UA UI Elements
    • ICB
    • Layout Viewport
    • window.innerHeight
    • 100svh/100dvh/100lvh
    • 100vh
    • Visual Viewport
  • Scenarios
    • Initial State (UA UI Expanded)
    • UA UI Contracted
    • Virtual Keyboard Shown
    • Virtual Keyboard Shown + Overlays Mode Enabled
    • Pinch-zoomed in
    • Pinch-zooming out
    • Scrollbars Present (Classic Scrollbars Forced via OS Prefs)
  • Tested Platforms+Browsers
    • iOS Safari (15.5)
    • iOS Chrome (103)
    • iOS Edge (103)
    • iOS Firefox (102)
    • Android Chrome (104 + Viewports Flag)
    • Android Edge (103)
    • Android Firefox (103)
    • ChromeOS Chrome (104)
    • macOS Safari (TP 150)
    • macOS Chrome (104 + FixedElementsDontOverscroll Flag)
    • macOS Edge (103)
    • macOS Firefox (104)
  • Platforms+Browsers not tested yet
    • Windows Chrome
    • Windows Edge
    • Windows Firefox
• We didn’t have time to discuss all findings, but only had time to review a few (not all in detail)
  • ICB: Android browsers resize the ICB when the Virtual Keyboard gets shown. This affects the size of the Layout Viewport, therefore affecting the computed size of the Dynamic Viewport Units.
    • At Google we are exploring if we want to move away from that behavior or not
  • Viewport Units on iOS: @dcrousso mentioned that there is a new API coming to iOS so that other vendors can properly implement Viewport Units. They already work in Chrome on iOS, but that might be through an unofficial API.
  • Fixed Positioning: Because browsers on Android resize the ICB+LVP when the VK gets shown, fixed positioning works differently when compared to iOS
    • See this demo page by flackr@
      • Option 1: iOS behavior
      • Option 2: Android behavior
      • Option 5: A new behavior we are exploring in [css-position-3] Reinterpret viewport positioned (fixed, sticky) elements wrt virtual keyboard w3c/csswg-drafts#7475
• @emilio wondered where we could note our findings. Perhaps in the css-viewport spec that was once talked about?
• @bramus screenshared some visualizations of the current ICB/LVP/VK behaviors
• @bramus closed off with a list of pre-compiled questions one could have about the behaviors. We agreed on creating individual issues for these in the repo, and label them accordingly.
• We discussed the next meeting: August 24, 2022. Same timeslot.

Action Items:

• @bramus: Merge test branch with test pages into repo
• @bramus: Finalize and publicize sheet with findings based on test pages
• @emilio: Ask CSSWG to actually create a css-viewport spec: [css-viewport] [css-device-adapt?] Really create a css-viewport spec w3c/csswg-drafts#7590
• @bramus: Convert questions list to issues
• @bramus: Send invitation for next meeting

[bramus]

Sheet with findings: https://goo.gle/interop-2022-viewport-testresults

(I already have a bunch of events logged, but have not added them to this sheet yet)