Any doc to explain why we should be using this viewport value?

[bitinn]

<meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui">

https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md#required-markup

This probably has something to do with 300ms click delay or rendering issues, but user-scalable=no is known to cause accessibility issues, is it worth the compromise?

Since minimal-ui is also a legacy keyword used by iOS Safari (added then removed), I am not sure why it's recommended neither.

Let me know if I should be asking this on StackOverflow.

[dvoytenko]

We will relax minimal-ui. Other properties guarantee good performance and usability in standalone and viewer scenarios.

[cramforce]

I think we can relax this a bit. This is mostly rooted in https://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization which relaxed without us nothing.

[bitinn]

@cramforce thx for pointing this out, if width=device-width, initial-scale=1, minimum-scale=1 works then I am all for it. width=device-width, initial-scale=1 being the standard viewport value nowadays.

[adactio]

Please, please, please remove the "initial-scale=1, minimum-scale=1" part. Not allowing users to pinch and zoom is awfully disempowering, particular for people with poor vision.

dvoytenko wrote "Other properties guarantee good performance and usability in standalone and viewer scenarios."

Good performance perhaps, but certainly not usability.

[dvoytenko]

We will definitely experiment with this a lot. The issue is that apps will be embedded AMP documents directly in their viewers and we need to ensure the portability between those.

[cramforce]

We should definitely find a good compromise here. Totally open to advice!

[adactio]

Actually, you know what? I think I may have spoken too soon: I thought there was a maximum-scale in there ...there isn't. Having initial-scale and minimum-scale should be fine.

I'll see if I can do a bit of research to confirm this. In any case, apologies for jumping the gun there.

[BPScott]

@adactio I'm still seeing maximum-scale=1 and user-scalable=no throughout the documentation and examples. Most obvious places are when describing the sample document and in the README.

I'll echo the existing claims that these should be removed to allow users to scale their content. There's not much point having blazing fast performance if people can't read the page once they get it.

The viewport I'd like to see (given minimal-ui is already legacy as pointed out by @bitinn) is:

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

[adactio]

@BPScott Right, the existing documentation does indeed still have maximum-scale=1 and user-scalable=no (and they're currently required for passing amp validation) but on this thread @cramforce said that it could be relaxed a bit and I assumed that @bitinn's suggestion was the option being discussed. I may have misinterpreted.

But yeah, maximum-scale=1 and user-scalable=no have got to go!

There's not much point having blazing fast performance if people can't read the page once they get it.

Exactly!

[jaicab]

Agree with @BPScott. Considering the use case, minimum-scale=1 would actually be a good thing.

[dvoytenko]

To review: we will definitely do a lot of experimentation and testing with these values on different browsers. The issues that are very important to us:

1. Obviously UX. It's clear that being able to zoom in would help readers.
2. Performance. We however can't jeopardize GPU rendering - things get really bad if we do. Looks like browsers have been relaxing their requirements from viewport for this, but we need to confirm and retest.
3. Performance of gestures. With pinch-zoom enabled browsers noticeably slow down gestures. E.g. "click" event arrives 200-300ms slower and so on. This is because the gestures become more ambiguous and browsers have to juggle more options before deciding, e.g., if something is a click or tap to zoom.
4. Universal viewer support. Different AMP containers in different apps and browsers should be able to support these values.
5. Interactivity in components: some components such as carousels and lightbox could be negatively affected. Interpretation of most basic things like position:fixed could vary drastically from platform to platform when pinch-zoom is activated.
6. Publisher choice. Even if we relax this rule, most of publishers that we reviewed so far already using "maximum-scale=1" today.

We will definitely try, but I don't think we are ready to tell how well this would work yet. I do hope however that we can at least make it an author choice.

[asimpson]

I'm happy to see that there will be more experimentation and investigation into this, as a11y is a critical aspect of the web.

Publisher choice. Even if we relax this rule, most of publishers that we reviewed so far already using "maximum-scale=1" today.

Isn't this basically a reason to consider not using maximum-scale? Most publishers have shown a blatant disregard for a11y and the web in general. My interpretation from reading the docs for AMP HTML is to provide a "sane default" for the web, I think this falls into that category.

[dvoytenko]

@asimpson

Isn't this basically a reason to consider not using maximum-scale?

Adam, yes, that was my point exactly. That's the motivation. And if something will prevent us from doing it now we will definitely take it to the browsers.

[alastc]

I'd echo (+1) @BPScott's point, we do a lot of work in accessibility and the ability to expand (by at least 200%) is a key requirement for accessibility, and a lot of people who don't necessarily class themselves as needing accessibility help.

Having applied it a lot, the only negative that I can see a publisher complaining about is when elements expand outside of the body-width. Typically an ad banner is set at 500px in a body width of 320px, and then you see horizontal scrolling which makes it more likely to accidentally zoom.

I think AMP could easily overcome that with things like max-width on images etc.

[patrickhlauke]

5 Publisher choice. Even if we relax this rule, most of publishers that we reviewed so far already using "maximum-scale=1" today

Most publishers also do lots of other things, like adding JavaScript to their sites...which doesn't mean AMP needs to include that either, no? As many others, I'll echo that disabling zooming (and mandating this at spec level) is a non-starter for accessibility.

[bitinn]

As suggested by @BPScott and me, if width=device-width, initial-scale=1, minimum-scale=1 works to allow GPU Rasterization (as pointed out by @cramforce), then I think it's a fine choice.

Note that it's minimum-scale=1, not maximum-scale=1.

To me maximum-scale=1 and user-scalable=no are too big a compromise for whatever fancy position:fixed design we can offer. It sucks, but that's the price we have to pay.

PS: I am looking at AMP as a future guideline for media/publishers, so getting a11y right means a lot more users will benefit from AMP. It's a tall order but somehow I think we can manage.

[brlewis]

@dvoytenko My recollection from when I worked on Google Image Search UI for tablet/mobile is that you can change the meta element via JavaScript to disable zoom, for example, when a lightbox is activated, then re-enable it later. That may help with issue 4.

[dvoytenko]

@brlewis thanks! I tested some aspects of this and came away feeling that it was rather flaky on different browsers especially when iframe'd, which is an important case for us. But we'll be definitely testing this more. Thanks for the suggestion!

[bitinn]

Another crazy idea: if publishers do want to use maximum-scale=1 and user-scalable=no to achieve whatever position:fixed design they have in mind, can we enforce them to have a print-friendly button or a built-in reading mode like Safari?

This feels like an anti-pattern: because by default your page should be accessible.

But from my observations, almost all publishers eventually violate some a11y rules to achieve the layout they are after. A strict validation rule on this prevent wide-adoption of AMP.

In that case, I would say enforce a print-friendly button (and they must be consistent and apparent), so even for ppl on non-iOS devices, a11y is an option.

My optimistic endgame for this:

• publishers see good data that many users are pushing their print-friendly button, so they scale back on doing fancy design that's inaccessible (much like today where you see users pushing the print button to avoid ads)

[WebReflection]

My thoughts FWIW,
in my experience ( developing twitter mobile Web client ) the currently used viewport solved a lot of cross platform/browser quicks related to rotation changes, where the UI could become suddenly different and never come back as it was originally, and also to scrolling performance + other quirks.

Apps users (80% of mobile users?) aren't used to pinch/zoom, they do that on images and maps eventually, rarely on browsers ... apps don't pinch/zoom.

If the font size is the default one, current viewport grants as-good-as-native visualization and if the user has not best eyes out there, the entire system usually will use the bigger font instead of the default small one.

Moreover, when it comes to images or maps, pinch/zoom on the whole page as default action becomes misleading instead of improving a11y.

Last, but not least, in all these years the DOM never even exposed a single standard way to retrieve the current zoom page ratio, once changed, neither an event capable of intercepting it (resize would be a workaround that might not even trigger) and being unable to actually handle these cases makes dynamic, X,Y handled coordinates, like in maps systems, harder to understand resulting on worst experience for the user.

TL;DR since most publishers, somehow first class target for this project, used already current restricted viewport which worked for them and their users, I think the specs should define a minimal set of options, as suggested before, and actually ignore anything else .... letting publishers decide if the user should be able to pinch/zoom/scale.

[TomVal]

OK, I'm the poreson who's severely affected by unability to zoom mobile web content due to "maximum-scale=1" and "user-scalable=no". My eyes are anything but good, but I still use them and I'm not using any screenreader yet, I prefer to zoom content to be able to read it comfortably. And the mobile web pages are often preventing me from it. So please, remove those damned viewport params from your example documents and validation conditions. Or is the mobile web really only for people with eagle-eye sight?

[alastc]

"Apps users (80% of mobile users?) aren't used to pinch/zoom"

We've had years of non-reponsive sites that you have to zoom in on, I think users in general are well trained to use zoom. Also, given the JS restrictions, are there going to be maps or similar interactive features in AMP pages to confuse the interactions?

"the entire system usually will use the bigger font instead of the default small one."

System level text sizing isn't applied in Safari or Chrome. (At least last time I checked. It isn't in Sarafi on iOS 9, I don't have an android/chrome browser to hand.)

TL;DR since most publishers, somehow first class target for this project, used already current restricted viewport [snipped].... letting publishers decide if the user should be able to pinch/zoom/scale.

The whole point of this project is that publishers sites include many anti-mobile patterns, and AMP is supposed to improve that. Saying that they do something now doesn't seem like a strong argument to continue it.

[TomVal]

@WebReflection If I get this correctly, amphtml is about documents, not app UI. I don't think anyone will use amphtml as an app framework, so pinch-to-zoom shouldn't be prevented, since there is a minority which depneds on this capability. And yes, web standards and browsers should sork differently with parts of web pages displaying actual documents and the rest displaying web app UI

[WebReflection]

@alastc I've met many people that never used the browser at all, passing though the app store for anything mentioned but yeah, since the mobile web hasn't been implemented that well so far, old desktop only sites requires pinch/zoom. Here we are talking about new sites that so far worked well with current restrictions: why would have publishers prefer them otherwise?

Moreover about maps, I don't see why this project couldn't be thought from scratch future compatible. So far is static content only but tomorrow there could be <amp-map> component with an image inside that gets enhanced on demand. Why not? Why would anyone lock already this initiative to static content only? I think it'd be bad for the future of this very same project.

In any case, I've said that this would be in my opinion the ideal minimum requirement:

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

but if there's more the AMP validator should just let it go instead of throwing warnings.

In this way we can still promote best practice, but not lock specs forever in case there will be games, maps, carousels or who knows which component in the future where the viewport, for whatever reason (games, maps, etc), might need to be fully locked.

[alastc]

why would have publishers prefer them otherwise?

There is an assumption they made a conscious choice about that, but perhaps they followed a default in some templates they were using?

I'm doing accessibility training for one of the named launch partners quite soon, and during the process of setting that up I found they didn't know about quite a few accessibility requirements, including the one for allowing zoom.

Your minimum requirement is fine, I would just like to see the docs & examples not require or default to disabling zoom.

I would also suggest that if disabling zoom is needed for working around bugs/quirks when there are interactive elements, perhaps we should work out what they are and try and fix them?

[kevinmarks]

Chrome does respect system size and also has a separate text zoom setting
itself on android.

The worst offending app here is Facebook. It completely ignores the system
font size setting and has no way to adjust the text size on android. I had
to install a 3rd party tool that patches the system font size to make it at
all legible for my wife on her phone.

The "must express everything in px" mantra of AMP is also annoying. I want
my inline images and videos to be 100vw on mobile, not some guessed pixel
width.
On 10 Oct 2015 3:30 am, "Alastair Campbell" notifications@github.com
wrote:

"Apps users (80% of mobile users?) aren't used to pinch/zoom"

We've had years of non-reponsive sites that you have to zoom in on, I
think users in general are well trained to use zoom. Also, given the JS
restrictions, are there going to be maps or similar interactive features in
AMP pages to confuse the interactions?

"the entire system usually will use the bigger font instead of the default
small one."

System level text sizing isn't applied in Safari or Chrome. (At least last
time I checked. It isn't in Sarafi on iOS 9, I don't have an android/chrome
browser to hand.)

TL;DR since most publishers, somehow first class target for this project,
used already current restricted viewport [snipped].... letting publishers
decide if the user should be able to pinch/zoom/scale.

The whole point of this project is that publishers sites include many
anti-mobile patterns, and AMP is supposed to improve that. Saying that they
do something now doesn't seem like a strong argument to continue it.

—
Reply to this email directly or view it on GitHub
#481 (comment).

[meyerweb]

I couldn’t agree more with @adactio’s assertion: “…maximum-scale=1 and user-scalable=no have got to go!”

[cramforce]

Kevin: Note, that AMP generally only uses pixels to calculate aspect
ratios. Put layout=responsive on amp elements and it flows into the
container; size the container in vw and you get what you want.

Would be great to finally get aspect ratio support in CSS, but I find the
way of expressing it in base size pretty nice. Open to other suggestions.
On Oct 10, 2015 10:55 AM, "Eric A. Meyer" notifications@github.com wrote:

I couldn’t agree more with @adactio https://github.com/adactio’s
assertion: “…maximum-scale=1 and user-scalable=no have got to go!”

—
Reply to this email directly or view it on GitHub
#481 (comment).

[KBDevelops]

It'd be interesting to know whether "user-scablable=no" would break WCAG 2.0 1.4.4 - Resize text. My guess it that it would and the requirement to have it on would mean that no AMP HTML website would be able to reach WCAG 2.0 AA standard as a result. I know the EU were concerned earlier this year about people disabling zoom off for mobile devices. If the aim is to make sites that work for people then all people need to be remembered, including those who need to zoom to read text on a page.

[dvoytenko]

Thanks all for the suggestions! We are going to involve accessibility experts on our side in a short order and experiment with all of the options. It's our goal to do everything possible to enforce a high accessibility standard throughout AMP universe.

[adactio]

@dvoytenko Glad to hear it!

Could you let us know who those accessibility experts are, or ask them to contribute to this issue thread?

Cheers.

[dvoytenko]

Few updates:

1. I added "gesture performance" to Any doc to explain why we should be using this viewport value? #481 (comment) - another important consideration. Most of browsers degrade the speed of issuing events noticeably with pinch-zoom on. Not a deciding factor, but also a consideration.
2. I confirmed: iOS Safari completely ignores "Large Text" setting. Not sure why, but if anyone has a background - please advise.
3. Another important consideration: if AMP itself enables pinch-to-zoom, the Viewer (e.g. Google Search, Twitter, Nuzzle, etc) would de-factor disable it if they do not use pinch-to-zoom themselves - and they all, of course, do. Perhaps opening up pinch-to-zoom could motivate viewers to enable it as well. Or perhaps we can make it a requirement, but a lot of usability issues still need to be confirmed.
4. Can anyone weigh in on "Zoom Gestures" on Android and iOS? They appear to work about the same on both platforms and they employ three-finger gestures to zoom screen irrespective of the type of app. I wonder how much are those in use and if they solve these problem?
5. I wanted to caution on "lightbox"and similar features as well. Talking to some of our accessibility folks - some aspects of lightbox/modals definitely conflict with pinch to zoom. E.g. with partial screen obscured in the modal it's hard to tell what just happened to the screen and many descriptive elements disappear, such as titles and "close" buttons. Perhaps, as @brlewis suggested, we need to disable pinch-to-zoom for modals.

[aarongustafson]

@dvoytenko Happy to offer a11y advice if you want it :-)

BTW - Just echoing the user-scablable=no is a bad idea requirement.

[patrickhlauke]

Maybe @alice has some thoughts on this...

[alice]

Sounds like @dvoytenko has it in largely in hand. Perhaps someone with more experience with zoom than me could respond to his questions (2) and (4) above?

[kevinmarks]

Regarding gestures, Chrome also has the 'double-tap to zoom text block to current viewport width' gesture that is extremely useful, but easy to trigger accidentally and hard to undo.

Pinch to zoom in modal images is also a natural feature; facebook's and twitters apps support zooming in their light boxes; indeed given the infographic plague it is a necessary one to read some things shared as images.

[alastc]

I'm a bit rusty on the Android side, but:

2. Safari probably ignores it because changing the text size within a responsive layout would probably break lots of layouts (which assume pixel heights etc.)
   That wouldn't be an issue for AMP initially, given the text-heavy nature of the initial context and partners, but I guess it would come up later.

3. Magnification (on mobile and desktop) is useful when navigating applications that have multiple areas visible on the screen and you can zoom in to read the text. However, magnifiers don't really work for full-width text (AMP's initial scenario).
   Imaging you can only read 1/3rd of a line of text at a time, and you have to scroll back and forth to read the whole thing.

When we've had people with low-vision in for usability testing they have generally had large Android phones (I haven't run any since the iPhone 6 came out), purely for the extra size of the display. People didn't generally know about the text-size settings, although helpful friends or charities sometimes change things for them.
I guess the best option on iOS is to buy a 6(s) plus, and set it to show at non-plus size, and use it in landscape a lot.

Currently (pinch) zoom on mobile works like magnification, however, a lot more people know about it and use it. Default features are always more used than specific accessibility settings. Also, if you try the three-fingered gestures, it is a lot more fiddly than a simple pinch zoom.

[jacobrossi]

Most of browsers degrade the speed of issuing events noticeably with pinch-zoom on.
Actually, pinch-zoom is fine. It's double-tap zoom that implies the 300ms tap delay.

Rather than user-scalable: no you can use touch-action: manipulation; in CSS. This will disable the 300ms tap delay in all browsers except Safari (Safari is considering adding this here) while still preserving pinch-zoom for accessibility and usability.

http://w3c.github.io/pointerevents/#the-touch-action-css-property

[dvoytenko]

@kevinmarks we will definitely have pinch to zoom in modals for images (lightbox). We already have double-tap and tap-to-zoom. Somehow pinch-to-zoom itself has fallen through the cracks, but we'll probably add soon. #446.

[dvoytenko]

Thanks everyone for advise. We are removing restrictions from maximum-scale=1 and user-scalable=no as you've advised. I'm removing "discussion" label from this issue and adding "intent to implement".

[dvoytenko]

Opened #592 to track implementation.

[cramforce]

Closing the discussion.

#592 tracks the implementation of what I believe everyone here is happy with.

Thanks for all the input! Truly appreciated!!!!

[adactio]

@dvoytenko @cramforce Thank you! 💯

[meyerweb]

Many thanks!

[dvoytenko]

All! Now viewport only requires width=device-width and minimum-scale=1. The validator is still lagging behind so I will send a separate notification when this is ready for use.

[WebReflection]

not sure it's relevant ... but maybe it is:
https://trac.webkit.org/changeset/191072

WebKit enables fast click only on non-scalable viewports

[dvoytenko]

It's relevant, but in this case we will leave this up to publisher to decide. Not all documents need fast click. And components that really care about this, such as amp-carousel and amp-image-lightbox, handle touch events directly.

[patrickhlauke]

regarding fast click, though webkit's change is welcome, it's about 2 years late compared to other browsers, and less problematic (from an accessibility perspective) solutions - such as removing the ~300ms delay for width=device-width, and the newer touch-action:manipulation - are now already implemented in other browsers - see http://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay

it's likely that touch-action:manipulation will make it into webkit at some point too, though - see https://bugs.webkit.org/show_bug.cgi?id=133112