scale shouldn't be spec'd as relative to the ideal viewport

[ChumpChief]

If the developer has modified the layout viewport size (e.g. meta viewport with width=1024 on a device where device-width would have been 384), pageScale should probably reflect the ratio against that adjusted viewport rather than the ideal viewport.

So I think this should instead use "layout viewport", though I'd be interested to make sure we're on the same page with the nastier cases you called out with wide elements and min-scale.

[bokand]

I think our hands are kind of tied here as it'd be very confusing if the pageScale in visualViewport wasn't the same as the minimum|maximum|initial-zoom in the viewport .

[bokand]

I listed some counter-arguments in Issue 35 but I'll sum up my thoughts here.

There's three arguments for keeping the status quo to me:

• This is the notion of scale authors today are used to. Its the same interpretation as used in the viewport tag today. Changing this would be confusing and make interaction between the meta specification and this API difficult
• I think "relative-to-ideal" is the more useful of the two. That's because it lets you convert between CSS pixels and DIPs. "relative-to-ideal" gives you a sense of how the page appears to the user which I think will be more commonly used:
  • The author wants to stick an un-zoomable header on their page (i.e. emulate device-fixed, e.g. "Install the App" banners). If the page has a wide viewport but expects the user to zoom in to see content, "relative-to-layout" means the natural approach would leave the header in the "small, unreadable" scale.
  • Makes it difficult to tell if the page is loading zoomed out or more generally how the page appears to the user. e.g. if a page wants to do analytics to determine how wide to make their layout
  • App wants to add detail when user zooms in to a level where it's legible (e.g. maps adding street names). "relative-to-layout" doesn't indicate how readable the content is.
  • With device-adaptation, the layout width can be more complicated so it'll be difficult for authors to reason about what a layout-relative scale factor means. E.g. width: 1280px auto; With "relative-to-layout" and scale=1, a page loaded on an iphone will look really different from a page loaded fullscreen on a 30 inch monitor. If the page wants to do something relative to page scale, layout-relative isn't a very useful notion.
• The layout width (i.e. the initial containing block, the width= part of the viewport meta) is distinct from the layout viewport, in Chrome at least. e.g. A really wide element can grow the layout viewport without affecting the ICB. This will make it difficult for authors to reason about what scale means if it's layout viewport relative. Making it relative the the ICB width would be even more confusing IMO. While it'd be nice to get interop on this, that could be a long process and may prove rather difficult. Last I checked, the edge cases regarding wide elements and minimum scales were completely varied between the major browsers. I'd rather we not rely on a quirky property to define scale.

There's use cases for "relative-to-layout" too, but given that it's easy enough to convert between the two I think it makes more sense to stick with the existing interpretation of scale. WDYT?

[bokand]

As another data point, see the use case in #23

[bokand]

@ChumpChief, WDYT about keeping it relative to ideal? I'd like to ship this in the next Chrome release to branch so I'd like to close out all the issues that would be difficult to change after shipping.

[hexalys]

One thought:

How would you assess what's the ideal viewport-width in split mode/view context? (e.g. iPad). Is ideal the outerWidth or the device-width? I wouldn't want an incorrect scale for that context.

[bokand]

The ideal viewport width in that case would be window-physical-width / window.devicePixelRatio. That is, it should work correctly even in a split mode or in a desktop window. Intuitively, it's just the window size without any pinch-zoom scaling applied (but accounting for browser-zoom and OS level UI zooming).

[hexalys]

I guess that works, as long as window.outerWidthand window.outerHeight are made standard across browsers, reporting the css pixel size at scale=1. At the moment, iOS still wrongly reports outerWidth/Height at 0, and both Firefox and IE include zoom scale to the window, unlike Safari & Chrome Desktop. But that's to address at spec level, and with Firefox+Edge, relating to lack of "desktop browser zoom" properties...

But FWIW, 'relative-to-layout' doesn't really change or affect the more common 'relative-to-ideal' cases. There are technically the same until the viewport is changed to other than device-width. For my use cases, I typically change the viewport dynamically after a read on initial values. So either way works. However, if an author has a static 'non-device-width' from the start, 'relative-to-ideal' could become problematic. Or even in my case, i'd prefer relying on the sub-pixel precision scale of the API in 'layout' terms as opposed to having to calculate it in a much less reliable manner (w/less sub-pixel accuracy).

[bokand]

However, if an author has a static 'non-device-width' from the start, 'relative-to-ideal' could become problematic. Or even in my case, i'd prefer relying on the sub-pixel precision scale of the API in 'layout' terms as opposed to having to calculate it in a much less reliable manner (w/less sub-pixel accuracy).

If you know the layout width then you can calculate the 'relative-to-layout' scale, it's easy enough to go to the 'relative-to-layout' scale: layoutScale = layoutWidth / view.width so I see this as a matter of which is more useful for the majority of use cases.

I see the main use case here as implementing position: device-fixed and other cases where you want to be independent of zoom. I think 'relative-to-layout' is strictly less useful for these cases because sizing things to the layout size is already easy to do (i.e. CSS width = 100vw).

[bokand]

I'm going to send out the intent-to-ship in Chrome tomorrow so I'll close this for the reasons I listed above and because it's easy to convert to relative-to-layout if desired. Please speak up ASAP if you strongly object to this.