Proposal: devs SHOULD NOT use content="user-scalable=no | maximum-scale=1.0 " on meta #602
Comments
|
Note that there are some (very specific) use cases where it may be valid to try and suppress user-initiated zooming/pinch-zooming, mostly around situations like maps (where you'd want to handle your own zooming programmatically, e.g. to load higher resolution map tiles, rather than allowing user to just blow up the current set of tiles). |
|
And note that before Safari's bold move to basically ignore meta directives that stop pinch-zoom, many browsers already included settings ("Force enable zoom", "Always allow zooming", etc) to disable this. |
that's why i am suggesting a normative SHOULD NOT rather than a MUST NOT |
|
sure, just suggesting it may be good to include this as a counter-example/exclusion in the actual prose |
|
post by @sturobson Don't do this in responsive web development |
|
There's already way too much content on the web using this feature gratuitously (meaning, without offering a custom-zoom alternative, and without respecting other user settings for preferred font size). Adding a warning to validators has little effect on that. The devs who are using validators are probably not the worst offenders. The way to most effectively get rid of this is at the user agent level. This could be done by making the feature completely obsolete, so that user agents are expected to drop support. Or it could be done by adding a requirement that user agents have a setting that allows users to override any author meta directives like this. (Which would allow the valid use cases to continue.) |
Which is what Apple just did (ironic, since they actually invented it), and most other UAs already have at least a setting to ignore it.
The feature is an Apple proprietary invention, and not actually spec'd officially (barring the retrospective https://www.w3.org/TR/css-device-adapt-1/#viewport-meta which is currently only a WD). that's the place where a warning should ideally be placed. [sent email to www-style to that effect, referencing this thread] Nonetheless, I don't see any harm in mentioning this in the HTML spec / adding a warning in the validator. It won't actually stop devs from using it, but... |
we don't know how much effect it will have, but i suggest even a little is a positive thing. Likewise with advice in the HTML spec. |
|
From past experience, this addition would be useful for getting managerial approval or increasing priority within a project, for example being able to say "It's not subjective - W3C spec says we should not be doing this", etc. |
|
@patrickhlauke For the maps use case, isn’t that a job for the CSS |
|
Just wanted to chime in from a different perspective just so it's captured and thought about. A lot of JavaScript games that can be played on a mobile device use that meta tag with As @patrickhlauke said, adding this as an example of when you could property use the meta tag would be helpful, especially if browsers start to disallow the meta tag, as one has done, game devs would have to find a different technique to disable zoom, pitch, and scroll for their games. If there was a definitive example of how to do that without the meta tag, that would probably still be fine but then a lot of older games would have to be updated to use the new syntax. |
|
If iOS force fully ignores the user-scalable=no, then it should not scrambles the other design too either the "width=320" or width=device-width is defined in the META tag too. As for now, it is breaking all the design which are not included inside 320px width. |
|
related email - @patrickhlauke to CSS WG https://lists.w3.org/Archives/Public/www-style/2016Sep/0130.html |
|
please review the commit text 29b8934 and provide feedback - thanks! |
|
issue raised on validator validator/validator#379 |
|
Hi everybody, I would like to join this conversation. Well ... All the points mentioned are right. Anyway it is funny that it is Apple which will give the user the freedom of zoom-in-out. Normally Apple user do not have the freedom to self-decide :D joking I would say this is working 90%. Means: Sometimes on text or pictures it is possible to zoom. I really don´t want to have the possibility to zoom-in-out for a specific project. So, if there is a better solution ... would be great :) Thanks |
ghost
mentioned this issue
|
Ability to disable zoomability on web pages is very important for web developers to be able to make performant games or sites with "app-like" behavior. We should note there is a dry reader mode on Safari that helps low vision readers with accessibility, if the site is such and someone needs those overrides. I tested on iOS 10.3 with a simple It's a mess! It's like putting the entire planet on a wheelchair just to guarantee that the differently abled are able to walk. As if all users are my users. That is simply not correct. |
|
I'm a developer. Let me decide how I want my app to be used. You can make yours fully accessible and I can make mine completely inaccessible, but that doesn't matter, we should all have a choice. Safari's move is crippling to freedom. |
|
I'm a user. Let me decide how I want to use an app. |
|
The user’s ability to manipulate the interface provided has long been a tenant of the web. Overall, I suspect there are far more sites that use max-scale=1 without needing to, compared to the sites which have a valid case. I’m curious about whether using a meta viewport setting is the best method to over-ride pinch-zoom for the valid cases like games and full-screen maps. If you are doing that type of app, presumably you are handling most or all gestures. If you are handling them, does the metaviewport even matter? (e.g. I notice that Google maps still works as intended on iOS.) |
|
@alastc we're missing the point here. It is an "accessibilty guideline" and not a law. Guidelines should be treated as such because otherwise it'd be something more draconian. If sites are misusing the clause without needing to and are downright inaccessible then those sites will wither away and die themselves. Why should a vendor extend life-support of such badly made sites and ruin the experience for everyone else for a longer period of time? Edits: working on making English my first language. |
WCAG is incorporated into many laws by reference. In the U.S., Canada, European Union, etc. While law / WCAG is not what this thread is about, I can't let that assertion go unaddressed. |
|
the spec reflects reality. reality is that Safari ignores any attempts at blocking resizing via if you don't like what Safari does, take it up with apple, not the spec. |
Awesome @chaals, so let me throw in some obvious features and reasoning behind this: 1. Let's take the case of iPads first. I know everything gets lumped together into one big category -- the "mobile web" -- but here we're on a nice, large and clear piece of glass with iOS Safari. Do we need pinch_to_zoom to bring up text any closer (appear bigger) than it already is on the iPad? Nope, not really. Much of the "scale_the_text" need is met by the sheer size of the tablet and the only meaningful usecases left to explore on iPad with pinchzoom are On the flipside however forcing pinchzoom to scale up the viewport almost always stifles the user experience (and the developer) at every step of the way. Safari/vendor incorrectly assumes a Thus a question: how will developers like me make a "tablet-first" website without first removing the burden of issues that leak from mobile world? Specifically, with our inability to prevent pinchzoom=>windowscaling simply. On accessibility, I know a few folks with low-vision challenges who bought the iPad only because of its physical size. Not one of them feels the need to pinchzoom for anything other than gaming, or deeper view of images or maps. Flamecharts is perhaps another example where pinchzoom is needed, but it's a developer usecase. My data here is obviously anecdotal but I can't think of a situation where the original purpose of pinchzoom/scaleWindow would hold good on a tablet. Also, there is From a dreamy HIPPO standpoint, I am leaning towards the fact that the screen size of iPads/tablets is large (being fairly close to that of a desktop) and that offline-first approach makes it possible to do complex apps on web. It is perhaps in our interest to let people choose a configuration for their apps simply. To that end it would be an important step for us to be able to disable pinchzoom on webpages, lock the parent frame at its initial position, and intercept multifinger touches for any other action like drawing, sketching, gaming, maps, interactive videos, AR/VR etc. My wife uses the iPad Safari to read books online like this: https://bubblin.io/book/pride-and-prejudice-by-jane-austen/1 Sacrilege interface from a "desktop/pointer-driven web" standpoint, but a real one nevertheless. 2. Case of smartphones. I know scratchpads need the parent frame to remain locked in its place. Most drawing apps, maps, games, video players would in general? I know that fullscreen api is coming to iOS Safari soon so at that point it will be important to not force pinchzoom/textscaling on every other usecase. Real estate may still be (was?) an issue on mobile, and we all know that content doesn't scale easily. Not without triggering a reflow. Responsive design helps but it doesn't solve the problem entirely, leaving us with sites having illegible text that could only be hacked over to scale with pinchzoom. And therefore, disabling pinchzoom even casually on a text-primary website is a strict no-go. I understand this and believe we are all on the same page here. Since we're on text scaling, let's take reflow into account more closely because it matters. A blogpost on Medium, for example, that is easy to scroll by on the desktop is rather inaccessible on mobile. Why so? A 5,000 words essay split into 20 paragraphs each looks great on the desktop. But on mobile the same blogpost reflows into a long and rather endless scroll in a shape of what some would call a thick "billing paper" roll. This makes the lower half of the article inaccessible by default. I guess anything that is over 10-20 swipes down can be safely assumed as inaccessible. Pagination helps here, but that's another story to discuss. I did a small experiment to highlight the issue with some swipe math: Here's a website (book?) on essentials of image optimisations by Addy Osmani. It took me ~90 (+/- 5) scroll swipes on the mouse to reach the end of the book while making sure I saw all of the content. Emulating real reading. The same site on iPhone 10 took ~194 swipes to scroll down to the bottom and ~244 swipes on an Android Galaxy Express 3 when making sure I saw all the content at least once. I don't know about others, but I'd never scroll down that deep into a scroll for any post that is longer than 30 swipes. Maximum 40. It's just too much to ask. Worse still, if I accidentally touch the bezel on top of my phone, the site scrolls back to the top from the middle of the book! Now I have to swipe back at least 92 times before I can reach the spot where I was lifted from. Anyway, we digress. So the point here is that accessibility is a double-edged sword and we can't apply (or force) a set of rules from one situation to another and expect to cover the entire spectrum of use cases on web in one broad stroke. Web is no longer a desktop-only paradigm. On these lines, the ability to disable pinchzoom/scaling without using javascript hacks is critical to the success of a web developer. IMHO, we should remain flexible and let people choose what is right for them/their audiences. Hence, the question: Is there a non-hacky way to prevent pinchzoom on iOS Safari Edits: Plenty. |
|
@aardrian Great point! All the more important for WCAG/web committees to not recommend accessibility guidelines that can be misused as laws by big-rigs as their corporate strategy! Some weekend dystopia fun: With Governments morphing into authoritarian regimes, it is important we be careful about choosing guidelines correctly with our future in mind, not just our current reality. @patrickhlauke we did! Not that they are doing this, but Apple (or anyone) could easily use accessibility guidelines from WCAG to mask their corporate strategy for native app stores and compel their decision on all developers. I understand that the spec is reflecting our current reality but it's certainly not a constraint. Nor should be. Although I admit here that I don't understand the process of "spec making" enough so my comments on this forum could easily be stupid. |
|
We seem to be heading off piste pretty quickly here, I'll try and keep this concise:
|
|
Good observation @alastc but unfortunately your conclusions are incorrect.
On epubs, epubs don't live on web. And that's a bad thing. You're effectively sending people away from web because of the inability to handle longform as was discussed on point #2 of my note above. Glad that the limitations of mobile web bring these weakness of the spec out better, not only for books but also for other stuff like blogposts and plain text articles that reflow too long.
All the cases I've quoted are relevant and real on web, it's another matter you respect those ideas or not. |
|
WCAG 2.1 should be published as a recommendation in June 2018, and still includes that requirement because it is a valid & useful requirement for users (it adds other requirements as well). User requirements are more important than developer requirements (as per WHATWG / W3C priories), and ultimately if the browsers work that way, the spec should reflect that. You might consider it a weakness, others do not. Anyway, it looks like this bug was closed a couple of years ago... |
|
Sure, I was talking about real user requirements (average people not developers) with a clear scenario of (i) tablets where pinchzoom is likely if not completely unnecessary and (ii) the issue of scrolls on mobile that grow too long to remain tolerable or even accessible due to reflow. Both points that you clearly did not address. I'm sure that this issue will be revisited again sometime in future, so leaving my comments up here for reference then. Until then committee, adios. ;-) |
|
@marvindanig "Do we need pinch_to_zoom to bring up text any closer (appear bigger) than it already is on the iPad? Nope, not really." well, clearly that's just your opinion, and a fairly broad-strokes generalisation at that. just because YOU don't think something's a problem, ever, doesn't mean that that's in fact the case. But yes, it's pointless arguing this point here anyway :) |
|
Would also note the Priority of constituencies from the HTML5 Design principles: |
|
This was a concrete practical issue, which was worth examining, and is potentially worth re-examining. But the discussion is getting a lot more heat than light. I'm tempted to close it down for a day or two, but won't yet because I hope people can focus on the issue. |
|
@chaals this proposal resulted in a SHOULD NOT author conformance requirement that has been in the spec since 2016 arronei@877b59c It is an author conformance requirement only, that does not forbid the use but does ask authors to consider seriously the curtailment of user's ability to zoom. What apple have done in safari is beyond the scope of this issue as it does not require anything of browser implementers. |
|
@marvindanig, taking my chair hat off and as an individual, I'd like to address a couple of points: Some people may well be happy with the iPad's physical size, instead of disabling zoom. People with "less than normal" visual acuity deal with it in a variety of ways. So sometimes, I am fine with normal sizes because I don't care about the detailed view - for example a map where I want a rough orientation. In other cases I will zoom really hard to e.g. read street names in very large font. The wdiely divergent forms of visual disability make this divergence even greater. (In general, "everyone I know" is a very useful basis for understanding a thing that people do, but a poor basis for extrapolating that nobody does something). I find your argument that disabling pinch-to-zoom on the iPad is justified doesn't match my own experience, let alone that of some people I know. Second, accessibility guidelines are not universal laws. The W3C's work is an attempt to formulate technical guidance for a world wide web. Personally, I am unhappy with many examples of adopting them as local laws - because I think there are better ways to make laws. If anything, the guidelines err on the side of caution, so they are likely to be less strict in requirements than is needed - and being technical work, we know they have bugs. But basically, a global communication network and application platform that excludes people just because they have disabilities is not fit for purpose, so accessibility issues do need to be fixed. The principles of the "priority of constituencies" are IMHO a better approach than "we can't be bothered implementing a browser well" or "we don't want some people to find our application functional". But the Web is a practical project, so compromises abound. Third, reading long form content is not the same as reading something short - either in experience, or the investment I am prepared to make. I rarely watch video because I rarely find it justifies the time, but I read a lot of long-form content. I'm used to the fact that it takes a lot more effort than reading trivial tweets, and do it because I expect to get more value. So again, I reject the idea that some magic number of scroll actions makes the content worthless, because it doesn't match my experience nor that of many users I know who are prepared to read long-form content despite immense difficulty based on a need for interacting with it by making the characters one inch high. |
|
Thanks @stevefaulkner, that's an important bit. The spec appears to be correct about SHOULD NOT author conformance requirement but does it emphasize that enough? 'Cuz Apple seems to be pushing a way more draconian interpretation of those lines -- a near "MUST NOT conformance requirement" instead. Of course it helps their cause of "great performant apps" in appstore as well. On my project (bubblin) we handle longform (books) in a very specific way. The parent window doesn't contain any content. This may be unique to us but all our books are paginated using iframes in what works like a real book. My readers still need I need to be able to lock the parent frame and enable pinchzoom at the level of book. This used to be straightforward in earlier versions of Safari but now it's completely broken. And it's rather difficult and expensive (performance hit) to fix it, and not even possible without using hacks at multiple levels. Even standard things like @chaals quick notes:
But it does make the container less (Methinks, we're on same page with all of this, correct me if I'm wrong.) My note above (point number 2) isn't about challenges of long-form at all. I am talking about inaccessibility of something that was "short" or "concise" on the desktop but is "too long" on mobile, and therefore inaccessible. Example: Open this blogpost on a desktop: https://medium.com/retronator-magazine/pixels-and-voxels-the-long-answer-5889ecc18190. Proceed to read (make that investment) and you'll be able to do that with fair bit of effort. Now reopen the same blogpost on a phone. Try finishing the article now. You'll find that it is impossible to do so. And oops!, even God cannot help if you accidentally touched the bezel on top of your phone. Is this a new kind of previously unaddressed inaccessibility? That said, feel free to reject all my thoughts, feedback and ideas. Mean no disrespect; been a web developer for 15 years and have only thanks to return for the beauty of collective thinking of one and all. |
|
I found an issue with mobile browsers not respecting the position of fixed that I applied to a static header. On scroll it would get partially obscured. I found an article that suggested using js libraries to handle the position fixed situation but warned of the issue of increased complexity and other bugs surfacing due to this fix. I found that applying user-scalable=no fixed the issue. Yes, it decreases accessibility and is a fix that I put in place until I find something better, but I think that generally speaking, if your user needs to zoom to read something, then your designs missed the mark. Of course some people have vision impairments and they need to zoom, which is why I'm on the lookout for a better option. |
The use of the
content="user-scalable=no"andmaximum-scale=1.0on themetaelement:<meta name="viewport" content="user-scalable=no"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">Causes real problems for users on mobile/touch devices. It stops them from being able to zoom content to suit their needs.
One browser has stopped zoom disable being effective: details https://wouterdeschuyter.be/blog/how-to-disable-viewport-scaling-in-ios-10-you-dont-941140811
What I am suggesting is that a normative author recommendation be added to the spec to discourage use of these values along with advice on why. And that conformance checkers should flag uses of these values with a warning.
cc/ @patrickhlauke @sideshowbarker
The text was updated successfully, but these errors were encountered: