meta viewport initial-scale=0

[miketaylr]

I don't know where the right place is for meta viewport -- maybe here. Maybe somewhere else. That said, Fennec got a bug report that had a weird thing:

<meta name="viewport" content="width=device-width, initial-scale=0">

Should figure out how Blink/Safari handle that and define it somewhere. @frivoal, do you guys document meta viewport in CSS Device Adapatation?

cf. https://github.com/webcompat/web-bugs/issues/2293

[karlcow]

In Gecko, the initial value is fetched here. https://dxr.mozilla.org/mozilla-central/rev/f9f3cc95d7282f1fd83f66dd74acbcdbfe821915/dom/base/nsDocument.cpp#7401

GetHeaderData(nsGkAtoms::viewport_initial_scale, scaleStr);

And converted to a float

mScaleFloat = LayoutDeviceToScreenScale(scaleStr.ToFloat(&scaleErrorCode));

which is used in return

https://dxr.mozilla.org/mozilla-central/rev/f9f3cc95d7282f1fd83f66dd74acbcdbfe821915/dom/base/nsDocument.cpp#7492

CSSToScreenScale scaleFloat = mScaleFloat * layoutDeviceScale;

which would mean 0

And maybe the issue is happening here https://dxr.mozilla.org/mozilla-central/rev/f9f3cc95d7282f1fd83f66dd74acbcdbfe821915/dom/base/nsDocument.cpp#7513

when comparing this value to min and max. I think this code doesn't really handle the case where the value is inferior to the viewport min size.

Now the interesting bit would be to see what WebKit and Blink do with this. Do they special case and interpret 0 == bogus.

[karlcow]

Also to answer a bit of @miketaylr question. According to https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale

The properties are translated into 'zoom', 'min-zoom', and 'max-zoom' respectively with the following translations of values.

1. Non-negative number values are translated to values, clamped to the range [0.1, 10]
   1. Negative number values are dropped
   2. yes is translated to 1
   3. device-width and device-height are translated to 10
   4. no and unknown values are translated to 0.1

For a viewport <META> element that translates into an @viewport rule with no max-zoom declaration and a non-auto min-zoom value that is larger than the max-zoom value of the UA stylesheet, the min-zoom declaration value is clamped to the UA stylesheet max-zoom value.

so I guess, the first thing we do wrong on Gecko is that we do not clamp to 0.1 Created https://bugzilla.mozilla.org/show_bug.cgi?id=1313264

[karlcow]

On Blink code: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ViewportDescription.cpp

[frivoal]

do you guys document meta viewport in CSS Device Adapatation?

We currently document it informatively, by defining how it works in terms of @viewport semantics. We have a recent resolution which I have not applied yet to convert that into being normative. That resolution includes slapping a big warning about the fact that differences between the specification and implementations are more likely to be accidental than to be attempts at pushing implementations to change, so anyone noticing a difference between what we spec and what browsers do should probably file a bug on the spec rather than on the browsers (at least at first).

So, aside from the fact that I am late in applying that resolution, I (and the CSSWG) would very much appreciate information about areas where implementations differ from the spec or from each other.

[karlcow]

@frivoal excellent. You should get this before the end of December.

[miketaylr]

Thanks @karlcow and @frivoal!

[karlcow]

Another interesting corner case to keep in mind. https://webcompat.com/issues/3645#issuecomment-259609913

• <meta name="viewport" content="width=device-width">
• with body set to min-width: 1000px (>to device size)
• and overflow-x: hidden

On Firefox we can't scroll on the side, nor zoom-out to see the full content. On Chrome the content has been resized to fit in the viewport.

[karlcow]

Note to self: To test the initial scale values issue from https://github.com/webcompat/web-bugs/issues/3498#issuecomment-259732997

[wisniewskit]

Also remember to check the initial-scale in #3789, please and thanks.

[karlcow]

Working on https://github.com/webcompat/web-bugs/issues/3789 and reading https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale The spec literally says for "The initial-scale, minimum-scale, and maximum-scale properties "

The properties are translated into 'zoom', 'min-zoom', and 'max-zoom' respectively

aka initial-scale = zoom.

So I created a test http://la-grange.net/2016/11/30/moz/initial-2.html

which indeed seems to achieve the zoom effect I was expecting. I need to test a bit more. But with that in mind I wonder if Firefox core team could reuse that for emulating/implementing the zoom: on both mobile and desktop. https://bugzilla.mozilla.org/show_bug.cgi?id=csszoom

[karlcow]

Zoom is also issue #41 (connecting dots)

[miketaylr]

https://bugzilla.mozilla.org/show_bug.cgi?id=1323062#c4 shows that wsj.com is using 1.0001 values to work around an iOS9 bug, which breaks Fennec.

That insane workaround is suggested here: https://forums.developer.apple.com/thread/13510

[karlcow]

Note: Explaining 3.b, WebKit often sees pages that define width=device-width but then explicitly layout content at very large widths, often greater than 1000px. These sites are usually designed for a large screen, and have added a viewport tag in the hope it makes it a mobile-friendly design. Unfortunately this is not the case. If the browser respected a misleading viewport rule such as this, the user would only see the top left corner of the content—clearly a bad experience. Instead WebKit looks for this scenario and adjusts the zoom factor appropriately. Conceptually, this behaviour is the same as the browser loading the page, then the user pinch zooming out far enough to see all the content, which means the page is no longer at a scale of 1.

in https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/

[karlcow]

Now, we ignore the user-scalable, min-scale and max-scale settings. If you have content that disabled zoom, please test it on iOS 10, and understand that many users will be zooming now. https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/

[karlcow]

About the 1.0001 value in iOS https://github.com/WebKit/webkit/blob/04c2bea6721a142bb73f9626e646c5aa5251c2d8/Source/WebKit2/Shared/CoordinatedGraphics/SimpleViewportController.cpp#L118

[karlcow]

so… the specification is wrong for initial-scale. Here my tests and results. https://bugzilla.mozilla.org/show_bug.cgi?id=1313264#c5 Firefox has a bug and a different behavior than other browsers.

Both Safari and Chrome have 0.25 as a clamping value and not 0.1 I wonder if someone from @microsoft could tel us the values for mobile.　@RByers @TheWebjustworks

[RByers]

@bokand is the chromium expert. Dave?

[bokand]

Yeah, that's correct -- Viewport zooms are clamped to 0.25 and 5 (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLMetaElement.cpp?type=cs&q=HTMLMetaElement&l=397).

If you need someone to describe how Chrome behaves under various viewports I can help. The case you mentioned above about content being wider than the layout width is particularly quirky and I think handled in different ways among all the browsers.

[karlcow]

Thanks very much @RByers and @bokand

@dstorey Do you know if Edge on Mobile is clamped at 0.25?