Unfortunately this also disables it on sites where it makes sense. For example I have a simple tool to pick a random person or split people into groups https://playerone.kevincox.ca/
Without zoom disabled 5 people putting their fingers on a screen looks a lot like a pinch gesture. Disabling the default event handlers only works some of the time.
This is a common problem with the web, we can't have nice things because people use them poorly.
Yep, exactly this. I have that setting enabled myself due to e.g. Blogspot inappropriately blocking zoom in its default mobile template — but on the other hand it does unfortunately mean that e.g. on openstreetmap.org I occasionally end up zooming the page instead of zooming the map…
That tool is a gem! I didn't have many situations where I could have used this during the past two years, but things seem to become a little better now.
I kind of wish the author had lead with this instead of burying it at the bottom. For whatever reach the article gets, this is the part that's going to offer value to readers (it seems unlikely this article will sway a significant number of web developers to change their habits).
The goal isn't to help the readers though, it's to convince web developers to fix their websites.
Anyone can find the secret override setting if they're motivated, but that's not a solution to the problem.
I know web developers don't care, but they're still the ones that can actually solve the problem. It's possible that like many other abused web features, Google will eventually change the setting for this feature from "override website zoom settings" to "respect website preferences for zooming" with "off" as a default.
I dunno. This article is like a 2 minute read. Starting with a solution nobody asked for sounds like an unreasonable request, while I did like hearing about these options after realizing how big the problem is.
Yup but it seems to me like the default behavior should be reversed. It should be accessible by default, and for the few special cases sites where zoom interferes with their functionality, then the setting could be toggle to disable it.
Additional headers on every request should only be considered if there really is no other option.
For not disabling zoom the header does not even help because developers blindly copy pasting the <meta name="viewport" ...> line so that broken by default mobile browsers won't fuck up their responsive design are not going to handle that header.
Like many accessibility issues, zoom is not something that only benefits a subset of the popultaion. The solution is to no disable zoom for anyone except the 0.01% of pages (only very specific web apps really) where zoom does not make any sense AND interferes with some other behavior (e.g. multi touch).
It’s not just accessibility. I’ve last track of the number of times I’ve seen a mobile website with a table that extends past the right side of the viewport and zoom disabled. You can’t scroll, and you can’t zoom, so you can’t read the table.
I think what you just indirectly pointed out is that software is largely written by young, ignorant people who don't appreciate that everyone will get to experience presbyopia, and it happens sooner than you think. Maybe we should require product owners to be at least 40 years old ;-).
I have the default font size boosted slightly. A large percentage of web sites and applications don't work with it, the text is cut off. Even ones from Microsoft.
The irony is you have to work to get this to not work. HTML by default will render just fine. Developers just can't resist customizing it so it doesn't work.
My web sites use plain HTML as much as possible. They're derided for being "Web 1.0", but they work, load in a flash, can be resized by the user, are legible, etc.
Even Apple went with pages that were light grey text on white with a tiny font. My eyeballs would just hurt trying to read it. This was a few years ago, maybe they fixed it, but I grew to avoid reading Apple's online docs because it was literally painful.
> normally sighted people or even people with "normal" nearsightedness, farsightedness, or presbyopia benefit from adequate contrast.
Makes me think of the oxo good grips kitchen utensils. They were designed designed for people with poor dexterity and as a result have become easier for everyone, this has made them extent l extremely popular
> Unfortunately people see accessibility as a burden that a small minority puts on the rest of us, but really it is something that benefits everyone
Depends on the individual case — I’ve seen entire projects get scrapped because it wouldn’t be feasible to make an “accessible” version. Some things just aren’t work for everyone and that’s okay.
Maybe this is a good place to ask since there's a lot of web devs here:
What is SO effing hard about drawing within the screen on web?! I can't tell you the number of times I've seen this issue. Just the other day I saw reddit's sign up form is totally broken on iOS, you have to swap between landscape/portrait multiple times and hope whatever garbage layout engine it uses redraws the button inside the screen.
It's because designers work with placeholder data. I worked full-time as a dev and saw this over and over and over again. The good designers would adapt, but some never learned.
As soon as you put real data into a website, especially if the website is a CMS that you've handed-off to a _non-technical_ client, it's going to overflow every pretty, grid-based box.
I think it's because almost all web design happens on computer screens, not mobile devices. More important, all web designers show their bosses their creations on a big computer screen in a conference room--the bigger the better so everybody can go "oooh!" and "aaaah!" and the designer can get a big fat raise.
I expect it's fairly rare for the employer of a web designer to give a shit what the site looks like on a phone, which means the designers don't give a shit either.
It starts with the fact that designs, and the development that uses them, usually think in terms of fixed rectangles. You've got a 1920x1080 desktop rectangle and a 375x812 mobile rectangle and rarely is much thought put in to what happens when your viewport is a different size. And what thought that is put in goes toward horizontal differences, since the assumption is that things will just scroll vertically.
But, as you've noticed, with more complex UI (especially modals and toolbars fixed to the screen) it becomes more important that things are built to fit horizontally and vertically. It's not necessarily hard but it does take more thought to work out how things will shrink, grow, scroll, etc.
> What is SO effing hard about drawing within the screen on web?!
It’s because the web’s layout primitives don’t compose well. There’s no easy way to say “this is a full-width container and nothing inside it can go off screen.” As an obvious example, any descendant of that container can use fixed positioning and do whatever it wants. But there are subtler examples that are easier to fall victim to. The way to fix this is to built your own higher-level layout primitives and have conventions or tooling to enforce that you compose them only in approved ways.
This is a constant issue for me (Chrome on Android) on GMail's Web UI (yes, I insist on using the Web UI...). So many emails are entirely unreadable since they go right off the right side, and you can't zoom.
I know exactly what you're talking about. A lot of times those tables are sized exactly for a horizontal view, so always try tilting your phone 90 degrees and it may work.
It's just constant. I know I am an oddball but I use firefox, which at this point is basically unsupported online. Pages just _dont_ work right. Of course my 600 extensions, from tridactyl(vim kb) to no script tend to break even more.
But it frustrates me to no end that a browser is no longer a "User" Agent and is now just seen as a... virtual machine for apps?
As a fellow Firefox user this is not my experience at all. Most stuff works fine once I allow the necessary subset in uMatrix. Some things are a pain in the ass, like embedded video widgets that need to load in dozens of scripts from all over the web before they'll finally get to the actual video frames, but I can pretty much always get stuff to work.
One tip: Don't try to install too many general filtering extensions (uMatrix, Privacy Badger, uBlock Origin, etc...) at the same time because they will end up fighting.
Another maddening thing are tiny fonts on mobile devices and pinch zoom does not reflow text. So you can't read without zooming in, and you can't see the whole page when you do, so you need to put your phone in landscape mode and drag left and right to read each and every row.
This is mostly due to the broken by default rendering of mobile browsers that emulate a larger desktop browser window unless the website specifically opts into the sane responsive behavior via the <meta name="viewport" content="width=device-width, initial-scale=1"> tag. This is especially idiotic since mobile browsers now have an explicit desktop mode that forces this behavior.
Sometimes you need to prevent zoom in order to implement your own zoom though.
For example if you're making a WebGL app, or if you're making a map zooming widget that needs to progressively load more local detail as the user zooms in on an area.
If you don't disable zoom, the OS and your zoom logic will be fighting over the pinch gesture.
maximum-scale and user-scalable=no seem like browser mis-features. Perhaps the OP would have more success appealing to browser developers to follow Apple and Samsung’s lead, and get browsers to ignore them?
It's definitely always a mis-feature for websites. It can make sense for webapps in rare cases [0]. Well, disabling the pinch gesture makes sense for those, ideally the browser would still provide another way to change the zoom.
What mobile browser? On iOS Safari, all the example websites mentioned by the OP allowed me to zoom. I guess Safari doesn’t allow zoom to be disabled by websites? Maybe all browsers should work this way?
I use iOS Firefox, because I love desktop Firefox and I have Firefo set up with account sync across all my devices. But there's a feature of desktop Firefox which isn't available on the iOS version: remember zoom setting for a domain.
iOS Firefox does have pinch-to-zoom, but having to use it every time I navigate to a page is tiresome.
iOS Firefox is a small niche choice and not the same codebase as desktop Firefox because Apple requires that you use their rendering engine. So I'm not sure it makes sense for Mozilla to dedicate the kind of resources to it to implement all the features I might want, and I don't have a lot of gripes. But as a datapoint in this thread, zoom is really important to me, and I miss it when it's not available. I shake my head every time I visit Google search results on my iPad because the text is so tiny.
My pet theory: I'm pretty sure this is because when HTML5 became a thing, some major tech blog showed us what an HTML5 page would look like (simplified doctype, meta charset) and they included the viewport settings that disabled zoom.
Then pretty much everyone copied from these guides, and here we are. I remember I had used HTML5 skeleton templates for a while before I learned that the "maximum-scale=1, user-scalable=no" they came with is not a good idea.
Almost all major template for JS frameworks these days include that line. And there are tons of guides that specify adding that in.
I get why it's there, if you're building a PWA that is supposed to mimick a mobile app, you have to enable that to override some annoying mobile browser behaviors like zooming on an input.
The problem is that the above scenario is about the only time you would want to set the viewport in that way. Yet because the line gets included in boilerplates to make it easier to make PWA's, it ends up in a ton of stuff that definitely is not a PWA and should not have that.
Fun fact: the reason why browsers sometimes zoom in on an input is because the input's font size is too small, less than 16px, which is considered not accessible. So it's ironic that to counter that behaviour some people make the page even less accessible by disabling use zoom.
> override some annoying mobile browser behaviors like zooming on an input.
Yep, I've seen some people disable zoom in their webpages specifically to prevent Safari from auto-zooming all over the place as the user moves from this to that input. It gets really annoying if you have anything but the simplest form. And what webpage doesn't have at least one form on it, even just the search box?
I fully agree with OP that disabling zoom is wrong. I also think it's wrong for browsers to mess with the zoom level without the user's instruction.
Almost every weird workaround we still have today in webdev was originally written to compensate for inconsistent browser implementation of some standard. In the past, IE was the one that always did something weird. Now it's Safari. Until browsers stop trying to pretend that they know better than both the developer and the user, somebody somewhere will keep writing these workarounds that then stick around in boilerplates and tutorials for years.
Classic Hanlon's razor "never attribute to malice that which is adequately explained by ignorance"
Copy-pasting a template and just not being aware of accessibility and functionality requirements is most likely explanation here. Or devs being given 4k UHD monitors and never looking at their work on a small laptop.
In the late 90s and early 2000s every second bank round these parts decided to do their entire website in Flash. Not just some animations and videos, but I mean the actual entire content of the site was Flash, no HTML. As well as being basically unusable search engines wouldn't index it either so you couldn't find anything.
Also fun was being deep in one of those "rewrite the web browser in Flash" pages and realizing you made a mistake so you hit the back button and lose all of your progress as the whole page is unloaded. Sometimes I look at web frameworks and think that these developers are nostalgic for the days of Flash.
I can confirm that theory. I wrote my own HTML5 template for my blog when HTML5 was pretty fresh. I don't recall where I exactly got the boilerplate from. I thought it might have been html5boilerplate.com, but I just checked the v1.0 tag and that doesn't prevent zooming in. But I definitely took the tag from someone and just applied it without knowing what it does.
If we want a free and open internet, why is the current web designed to let server owners control our experience? This leads to accessibility fails like the inability for visually challenged people to control font size or contrast, but also leads to lots of other bad effects, like the fact that my browser gets more and more bloated every year and essentially has become a tool to let other people run programs (javascript and wasm) on my computer, and display content that they want (ads, etc.) rather than content that I want.
I really want an internet where servers provide structured content, but where I control my user experience.
>If we want a free and open internet, why is the current web designed to let server owners control our experience?
Because server owners have the freedom to publish whatever they like (within the bounds of the law) and design their sites however they wish. An internet on which servers are only allowed to provide "structured content" would be significantly less free and open.
You may be interested in the Gemini Protocol[0], on which sites are built according to that general principle.
They can send whatever data they like but they have no right of control over what I do with it or how it’s rendered. Browsers would be better if they prioritised user preferences over website designers.
Don't disable zoom, and stop fucking with scrolling.
Browser scrolling works fine. You don't need to try to re-implement smooth scrolling, it never works and makes my scrolling bounce around like mad.
One website override my scrolling speed entirely. I like it so that 1 click = 2 lines of scrolling. That site changed it to that 1 click = 1/2 line, but for some reason the web dev thought they knew better than my preferences.
I don't understand why the functionality exists for websites to dictate how users can and cannot view a page in the first place. This is like if you were reading a book that detected if you were trying to use a magnifying glass and immediately caused a glare to appear to prevent you from being able to read it. It is fucked up.
There was a fundamental shift about 15 years ago where webpages ceased to be markup documents (perhaps with some active elements for convenience) and became javascript applications that ran in your web browser.
To use your book analogy - the web is no longer a bunch of books on a shelf, it's an AR device that shoots lasers into your eye. The net effect may be the same in many use-cases, but not necessarily, and malicious actors now have far more flexibility and power because we've all become accustomed to running random code we download off the internet with a single click.
I am, obviously, not a huge fan of this shift and think a large majority of sites could operate perfectly well under the "markup document" model without needing actual code-execution privileges, or more than a minimal set of code-execution privileges for those actual simple document-related use-cases. Go back to being mostly just a book, basically.
Almost all of the use-cases that javascript gets used for in a document context could really be replaced by navigation between sets of linked, static pages (perhaps embedded where needed) - boy, what an idea. If you delivered a site "as a gzip" then there should barely be any noticeable size difference from that anyway, especially compared to downloading mountains of JS embeds.
The amount of things that truly, truly need interactivity is pretty low - things like chat clients come to mind, but does your bank need to be running javascript on your end? Probably not.
The choice to allow zoom, or scrolling, or window resizing, or even fonts and colors... basically anything that affects my web browsing experience, should belong to me as the user, not some web site developer 1,000 miles away from me. Browsers have taken way too much control from the user (or hidden it in Settings menus) and handed the controls over to web designers. Browsers have a setting to take back this zoom control, but really it shouldn't be a setting--it should be the default. The web developer should not have the ability to disable a feature of my browser any more than he should be able to reboot my machine.
I don't understand this argument. Leaving aside the fact that the examples provided in the link are hardly works of art, the "creator" has already created something the way they wanted to, as has every other website designer. And just like there would be no good reason for an editor to stop me from using a magnifying glass on a book that I bought, nor from writing notes in the pages or highlight parts of the text (advisedly or not), neither does anything justify disabling zoom.
For whatever reason, my Firefox was already ignoring these artificial restrictions intended by the creators, and I was able to zoom as normal. Does that affect the creators of these websites in any way whatsoever?
It is the creator's right to dictate the original presentation, but it is not the creator's right to dictate a user's behavior. Just like it is a filmmaker's right to set the default framerate and playback speed for a film, but you can rewind or fastforward, or play the film at X speed if you so wish in your media player.
Disabling or otherwise inhibiting user behavior is not a creator's right.
In the old days you needed to disable zoom in order to get click events immediately, rather than delayed a bit so it can tell whether it's really going to be a zoom operation. Is that still true?
Yea, still a 2-300ms delay, which is why I guess a lot of devs just disable zoom - that way they get that "instant native app" feel without actually having to think about it :)
Edit: Having just tried the sites in the Safari ... they zoom in just fine with that set, so .. Im a bit confused
100% agree. I'd like to be able to tell mobile Safari to just ignore that setting. Maybe there's a way and I missed it. Wouldn't be surprised, these old eyeballs aren't what they used to be and that exactly why I want zoom to always work. Some of us actually need it.
Heck, back when I bought my mother her first iPad, this was the whole reason. She was getting eye surgery and wouldn't be able to see well, and would be stuck face-down for a couple weeks. I figured an iPad would be good, because she could pinch-zoom so the letters were two inches tall if necessary. It was a roaring success, but zoom=false defeats that.
> I'd like to be able to tell mobile Safari to just ignore that setting
Mobile Safari does ignore this setting. You have to go out of your way with stopping touch events on mobile safari to prevent zooming.
Sometimes this is problematic for sites using "small" (< 16px) fonts for input fields because that will cause mobile safari to zoom in to show the input field whether you want it to or not.
Readit News
As a user, you can force allow zooming:
In Firefox find the settings, select “Accessibility” and activate “Zoom on all website”
In Chrome find the settings, select “Accessibility” and check “Force enable zoom”
Without zoom disabled 5 people putting their fingers on a screen looks a lot like a pinch gesture. Disabling the default event handlers only works some of the time.
This is a common problem with the web, we can't have nice things because people use them poorly.
I've never been able to zoom on mobile apps.
Anyone can find the secret override setting if they're motivated, but that's not a solution to the problem.
I know web developers don't care, but they're still the ones that can actually solve the problem. It's possible that like many other abused web features, Google will eventually change the setting for this feature from "override website zoom settings" to "respect website preferences for zooming" with "off" as a default.
The entire article barely scratches 250 words. I don't think anything can be considered 'buried' in what is basically a medium-sized paragraph.
In lieu of that, maybe consider having an "accessibility options" cta on first interaction.
For not disabling zoom the header does not even help because developers blindly copy pasting the <meta name="viewport" ...> line so that broken by default mobile browsers won't fuck up their responsive design are not going to handle that header.
Like many accessibility issues, zoom is not something that only benefits a subset of the popultaion. The solution is to no disable zoom for anyone except the 0.01% of pages (only very specific web apps really) where zoom does not make any sense AND interferes with some other behavior (e.g. multi touch).
For instance, normally sighted people or even people with "normal" nearsightedness, farsightedness, or presbyopia benefit from adequate contrast.
Text "size" is another thing because people should be able to control it, particularly given the wide range of different devices that are out there.
I think what you just indirectly pointed out is that software is largely written by young, ignorant people who don't appreciate that everyone will get to experience presbyopia, and it happens sooner than you think. Maybe we should require product owners to be at least 40 years old ;-).
The irony is you have to work to get this to not work. HTML by default will render just fine. Developers just can't resist customizing it so it doesn't work.
My web sites use plain HTML as much as possible. They're derided for being "Web 1.0", but they work, load in a flash, can be resized by the user, are legible, etc.
Even Apple went with pages that were light grey text on white with a tiny font. My eyeballs would just hurt trying to read it. This was a few years ago, maybe they fixed it, but I grew to avoid reading Apple's online docs because it was literally painful.
Makes me think of the oxo good grips kitchen utensils. They were designed designed for people with poor dexterity and as a result have become easier for everyone, this has made them extent l extremely popular
Depends on the individual case — I’ve seen entire projects get scrapped because it wouldn’t be feasible to make an “accessible” version. Some things just aren’t work for everyone and that’s okay.
What is SO effing hard about drawing within the screen on web?! I can't tell you the number of times I've seen this issue. Just the other day I saw reddit's sign up form is totally broken on iOS, you have to swap between landscape/portrait multiple times and hope whatever garbage layout engine it uses redraws the button inside the screen.
As soon as you put real data into a website, especially if the website is a CMS that you've handed-off to a _non-technical_ client, it's going to overflow every pretty, grid-based box.
I expect it's fairly rare for the employer of a web designer to give a shit what the site looks like on a phone, which means the designers don't give a shit either.
But, as you've noticed, with more complex UI (especially modals and toolbars fixed to the screen) it becomes more important that things are built to fit horizontally and vertically. It's not necessarily hard but it does take more thought to work out how things will shrink, grow, scroll, etc.
It’s because the web’s layout primitives don’t compose well. There’s no easy way to say “this is a full-width container and nothing inside it can go off screen.” As an obvious example, any descendant of that container can use fixed positioning and do whatever it wants. But there are subtler examples that are easier to fall victim to. The way to fix this is to built your own higher-level layout primitives and have conventions or tooling to enforce that you compose them only in approved ways.
Which makes the table content inaccessible. It _is_ an accessibility issue.
Here's the definition I prefer, that does not focus on "disabilities" (which many people equate "accessibility" with):
> When we say a site is accessible, we mean that the site's content is available, and its functionality can be operated, by literally anyone.
https://web.dev/accessibility/
But it frustrates me to no end that a browser is no longer a "User" Agent and is now just seen as a... virtual machine for apps?
One tip: Don't try to install too many general filtering extensions (uMatrix, Privacy Badger, uBlock Origin, etc...) at the same time because they will end up fighting.
Even better, one chrome issue/bug report, had google devs on the tracker explaining how it's fine, and how each website should just fix things.
They were blathering on about how websites are broken, should be fixed, utter absurd.
The sheer, unmitigated gall, of saying "screw users" is beyond comprehension.
Google: unless you want another series of Professor Farnsworth posters around HQ, fix it!
For example if you're making a WebGL app, or if you're making a map zooming widget that needs to progressively load more local detail as the user zooms in on an area.
If you don't disable zoom, the OS and your zoom logic will be fighting over the pinch gesture.
[0] https://news.ycombinator.com/item?id=31274454
iOS Firefox does have pinch-to-zoom, but having to use it every time I navigate to a page is tiresome.
iOS Firefox is a small niche choice and not the same codebase as desktop Firefox because Apple requires that you use their rendering engine. So I'm not sure it makes sense for Mozilla to dedicate the kind of resources to it to implement all the features I might want, and I don't have a lot of gripes. But as a datapoint in this thread, zoom is really important to me, and I miss it when it's not available. I shake my head every time I visit Google search results on my iPad because the text is so tiny.
Then pretty much everyone copied from these guides, and here we are. I remember I had used HTML5 skeleton templates for a while before I learned that the "maximum-scale=1, user-scalable=no" they came with is not a good idea.
I get why it's there, if you're building a PWA that is supposed to mimick a mobile app, you have to enable that to override some annoying mobile browser behaviors like zooming on an input.
The problem is that the above scenario is about the only time you would want to set the viewport in that way. Yet because the line gets included in boilerplates to make it easier to make PWA's, it ends up in a ton of stuff that definitely is not a PWA and should not have that.
<meta name="viewport" content="width=device-width, initial-scale=1">
Do you have links to examples of the major templates?
Yep, I've seen some people disable zoom in their webpages specifically to prevent Safari from auto-zooming all over the place as the user moves from this to that input. It gets really annoying if you have anything but the simplest form. And what webpage doesn't have at least one form on it, even just the search box?
I fully agree with OP that disabling zoom is wrong. I also think it's wrong for browsers to mess with the zoom level without the user's instruction.
Almost every weird workaround we still have today in webdev was originally written to compensate for inconsistent browser implementation of some standard. In the past, IE was the one that always did something weird. Now it's Safari. Until browsers stop trying to pretend that they know better than both the developer and the user, somebody somewhere will keep writing these workarounds that then stick around in boilerplates and tutorials for years.
Copy-pasting a template and just not being aware of accessibility and functionality requirements is most likely explanation here. Or devs being given 4k UHD monitors and never looking at their work on a small laptop.
I really want an internet where servers provide structured content, but where I control my user experience.
Because the most popular web browsers ARE created by some of the largest server owners (i.e. Google).
To address this, make sure your site works with simple browsers, like Links and lynx.
Because server owners have the freedom to publish whatever they like (within the bounds of the law) and design their sites however they wish. An internet on which servers are only allowed to provide "structured content" would be significantly less free and open.
You may be interested in the Gemini Protocol[0], on which sites are built according to that general principle.
[0]https://gemini.circumlunar.space/
Browser scrolling works fine. You don't need to try to re-implement smooth scrolling, it never works and makes my scrolling bounce around like mad.
One website override my scrolling speed entirely. I like it so that 1 click = 2 lines of scrolling. That site changed it to that 1 click = 1/2 line, but for some reason the web dev thought they knew better than my preferences.
To use your book analogy - the web is no longer a bunch of books on a shelf, it's an AR device that shoots lasers into your eye. The net effect may be the same in many use-cases, but not necessarily, and malicious actors now have far more flexibility and power because we've all become accustomed to running random code we download off the internet with a single click.
I am, obviously, not a huge fan of this shift and think a large majority of sites could operate perfectly well under the "markup document" model without needing actual code-execution privileges, or more than a minimal set of code-execution privileges for those actual simple document-related use-cases. Go back to being mostly just a book, basically.
Almost all of the use-cases that javascript gets used for in a document context could really be replaced by navigation between sets of linked, static pages (perhaps embedded where needed) - boy, what an idea. If you delivered a site "as a gzip" then there should barely be any noticeable size difference from that anyway, especially compared to downloading mountains of JS embeds.
The amount of things that truly, truly need interactivity is pretty low - things like chat clients come to mind, but does your bank need to be running javascript on your end? Probably not.
How much choice do you have in the typesetting of any book you've ever bought?
You could still use a magnifying glass on your monitor, as some Russian General was photographed doing recently... .
.
Obviously I think the choice to disable zoom, etc, is daft, but ultimately that is the creator's right to call, advisedly or otherwise.
For whatever reason, my Firefox was already ignoring these artificial restrictions intended by the creators, and I was able to zoom as normal. Does that affect the creators of these websites in any way whatsoever?
Disabling or otherwise inhibiting user behavior is not a creator's right.
1. There must be a meta tag of type viewport 2. The viewport must be defined to have width=device-width 3. The content must be at a scale of 1
Edit: Having just tried the sites in the Safari ... they zoom in just fine with that set, so .. Im a bit confused
Heck, back when I bought my mother her first iPad, this was the whole reason. She was getting eye surgery and wouldn't be able to see well, and would be stuck face-down for a couple weeks. I figured an iPad would be good, because she could pinch-zoom so the letters were two inches tall if necessary. It was a roaring success, but zoom=false defeats that.
Mobile Safari does ignore this setting. You have to go out of your way with stopping touch events on mobile safari to prevent zooming.
Sometimes this is problematic for sites using "small" (< 16px) fonts for input fields because that will cause mobile safari to zoom in to show the input field whether you want it to or not.