Viewport Investigation project

[jensimmons]

As part of #4, we agreed to do a small cross-browser research project into the current state of viewports on mobile devices.

Who would like to be part of this effort?

[karlcow]

I would love! Mozilla had to do a lot of reverse engineering to understand what was happening on Chrome and Safari. And there is still a lot of bugs which need to be addressed.

[jensimmons]

Excellent, @karlcow.

Is anyone from Microsoft interested? I would love for us to have someone involved to cover the Surface Duo. @aarongustafson @atanassov

How about anyone from Chrome? @una @argyleink @stubbornella

Samsung Internet? @AdaRoseCannon

Our goal:
To sort out any confusion about what “viewport” means, and what browsers (especially on mobile devices) should be doing with various viewport measurements & sizing. To make recommendations for what should change to improve interoperability.

Scope of Work:

• Come up with the actual plan —the group's goal and scope of work. (This is a quick draft.)
• Make a list of what measurements of the viewport we want to investigate (vh, window.InnerHeight, height: 100%, etc).
• Make a list of all the places in web standards (CSS, HTML, elsewhere) where viewport sizing is defined, collecting the text & links that define what these measurements are supposed to be.
• Make a list of which browsers + devices we will be looking into.
• Create a test page or three — perhaps like this: http://smfr.org/misc/viewport-units.html
• Create a shared spreadsheet where we can fill in all the data for what we find.
• Manually test these measurements in these browsers on these devices and fill in the spreadsheet.
• Write up a report someplace (a deck + PDF? A webpage?) so people can see the information we've gathered — both what viewport measurements should be, and what they currently are.
• Send copies to the CSSWG & others, whoever, as well as post online of course.
• Open any issues at CSSWG, WHATWG, wherever if we find underspecified standards on what these measurements should be in relationship to the viewport — so that the appropriate standards group can take it from there & define any missing details.
• Open any issues/bugs with the appropriate browsers, noting places where they are not aligned with the standard. Or if the standard is unclear, where they are not aligned with each other.
• Declare victory and leave with a much clearer understanding of the state of viewports.

That's what I'm imagining. Thoughts? Who else is in?

[aarongustafson]

Adding @ststimac to cover Duo.

[rachelandrew]

I'd be happy to be involved in this on the Chrome side.

[argyleink]

I can't commit to helping, but I can share some handy links!

• @bokand has extensive research from ~2018, sharing lots of results, ideas and considerations
• demo by David helps show an overview of the problem space

[jensimmons]

So we have:

• @jensimmons, from Apple (US east coast, ET)
• @rachelandrew, from Google (UK)
• @skobes, from Google (Canada east coast, ET)
• @ststimac, from Microsoft (US west coast, PT)
• @karlcow, from Mozilla (Japan)
• @AdaRoseCannon, from Samsung (UK)

Great. And ah ouch.... the timezones.

Does a 9am PT / 12noon ET / 5pm UK / 2am JP time work? Karl, I'm not sure what work hours you are used to doing.

Or this time zone calculator suggests 4pm ET / 1pm PT / 9pm UK / 6am JP.

Preferences?

Also, we can aim to have as few meetings as possible, and work asynchronously. But I'd like to start with getting together if it's possible.

[jensimmons]

Oh actually I misread the timezone calculator. There are several other times that might work, although they'll be at the very end or beginning of Rachel & Karl's day.

https://www.timeanddate.com/worldclock/meetingtime.html?month=2&day=1&year=2022&p1=179&p2=234&p3=136&p4=248&iv=0

[AdaRoseCannon]

I'd also like to drop in i'm stretched pretty thin right now but it's important issue to stay abreast of (i am also UK)

[jensimmons]

Excellent, Ada. I was hoping you could represent Samsung.

[rachelandrew]

I can do meetings up to 7pm my time, I don't mind doing the occasional one a bit later but I'm not much use to anyone late in the day as I'm an extreme early person. I'd be more enthusiastic about a meeting at 4am my time than 9pm.

Given we have the worst timezone spread I think it might be worth trying to do as much as possible async.

[jensimmons]

It looks like these times are the ones available. (Ignore the "Tues")

There are really two questions:

1. How early can you meet @ststimac? 6am? Or even earlier?
2. How late you can start @karlcow ? 11pm? 12am? 1am? 2am? Perhaps you work late a lot because of timezones.

10am ET / 7am PT / 3pm UK / 12 midnight JP may be our best time slot.

And yes, let's plan to do as much as possible async. Or perhaps we'll have a few PT / ET / UK timed meetings — at 12pm ET / 9am PT / 5pm UK / (also 2am JP) — and take good notes for Karl.

[ststimac]

6AM is the earliest I can start.

[karlcow]

@jensimmons Tuesday 11:00pm I already have the webcompat team meetings at this exact same time. And I start the Tuesday at 6am. So I would like to avoid after midnight BUT this is ok for me: "and take good notes for Karl." ❤️. I should not be a blocker if everyone has found the right time for them.

Thanks for asking.

[skobes-chromium]

Hi, I'd be interested in participating in this project. I have some familiarity with Chrome's implementation in these areas from past work on scrolling issues.

All of the proposed meeting times are generally ok for me, but +1 to working async as much as possible.

[karlcow]

In general, Mozilla Viewport issues are collected on Bug 1123938 - [meta] Make viewport handling consistent with other browsers

• Firefox doesn't handle body with height 100vh properly with overflow:hidden on the root element
• Using keyboard on inputs causes viewport to resize, shrinking elements based on viewport units.
• vh units size should be affected by minimum scale (or some such?)
• Consider moving the dynamic toolbar even if the root content height is smaller than 100% height but there's a position:fixed element whose height is over 100vh

The meta bug has many more interesting issues

These are three issues, but there are a bit more related to subtle interactions scenarios. Some sites do resize the width during a load, some sites have specific hacks for positioning their top bar assuming that the URL bar is always at the top, etc. etc. It's a minefield.

Not sure also if it's in the scope of the project, but there are also implementation issues related to the intersection of print and viewport units for example: vh & vw units are too large (and depend on DPI), in printed / print-previewed documents.

[jensimmons]

To update everyone — those of us going to the weekly meetings to plan Interop 2022 are still fairly busy with that work. I plan to kick off this committee once Interop 2022 has been launched (which should happen sometime in February).

This effort is not forgotten! Just too much to start yet, given all the ongoing debates and coordination required for the larger Interop 2022 effort.

[skobes-chromium]

• @skobes, from Google (location?)

Waterloo, Canada (eastern time zone)

[foolip]

As requested by @jensimmons, I've created https://github.com/web-platform-tests/interop-2022-viewport with a boilerplate README now. Everyone in the Interop 2022 team has write access, and we can also add additional collaborators who aren't part of that team.

[foolip]

Discussed in #77. @foolip will volunteer to sort out the logistics of a first meeting, if that would help.

[foolip]

@bramus from Google would also like to be involved.

[foolip]

I've scheduled a first meeting based on the input in this issue, and sent web-platform-tests/interop-2022-viewport#2 as an agenda/notes issue.

[foolip]

Closing this issue, discussion continues in https://github.com/web-platform-tests/interop-2022-viewport