Tag: Zoom

16px or Larger Text Prevents iOS Form Zoom

This was a great “Today I Learned” for me from Josh W. Comeau. If the font-size of an <input> is 16px or larger, Safari on iOS will focus into the input normally. But as soon as the font-size is 15px or less, the viewport will zoom into that input. Presumably, because it considers that type too small and wants you to see what you are doing. So it zooms in to help you. Accessibility. If you don’t want that, make the font big enough.

Here’s Josh’s exact Pen if you want to have a play yourself.

In general, I’d say I like this feature. It helps people see what they are doing and discourages super-tiny font sizes. What is a slight bummer — and I really don’t blame anyone here — is that not all typefaces are created equal in terms of readability at different sizes. For example, here’s San Francisco versus Caveat at 16px.

San Francisco on the left, Cavet on the right. Caveat looks visually much smaller even though the font-size is the same.

You can view that example in Debug Mode to see for yourself and change the font size to see what does and doesn’t zoom.

The post 16px or Larger Text Prevents iOS Form Zoom appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Can JavaScript Detect the Browser’s Zoom Level?

No, not really.

My first guess was that this was intentionally not exposed in browsers because browsers intentionally don’t want us fighting it — or making well-intentioned but bad-outcome decisions based on that info. But I don’t see any evidence of that.

StackOverflow answers paint how weird cross-browser it can be. This script from 2013 works for me in Chrome, but not at all in Safari and reports incorrectly in Firefox. Even if that script worked, it relies on user agent detection (which is not long for this world) and some incredibly weird hacks.

So please, feel free to correct me if I’m wrong, but I think the answer is that we can’t really do this right now.

There is a thing called the Visual Viewport API

I’m kinda confused by it.

  • The spec is a draft
  • The support chart lists a lot of support
  • window.visualViewport is defined in Firefox, Safari, and Chrome (desktop)
  • But… window.visualViewport.scale is always 1 in Safari and Chrome, and undefined in Firefox. In other words: useless.

I don’t entirely know if that is supposed to accurately represent the browser zoom level, because the spec talks about specifically about pinch-zoom. So, maybe it’s just not intended for desktop browser zoom levels.

What’s a use case here?

I had a fella spell out a situation like this:

He wanted to use CSS grid to layout cemetery plots (interesting already), like a top-down blueprint of a graveyard. There was lots of information in the layout. If you were “zoomed out” so you could see the whole graveyard on one page, the text in each area would be too small to read (sincethe type would be sized to fit within the boxes/graves). Ideally, the page would hide that text while the browser is zoomed out (perhaps a .hide-text class). When zoomed in far enough, the text is shown again.


// Dunno if "resize" is best. I don't know what the "change zoom" event would be window.visualViewport.addEventListener("resize", viewportHandler); function viewportHandler(event) {   // NOTE: This doesn't actually work at time of writing   if (event.target.scale > 3) {     document.body.classList.remove("hide-text");     } else {     document.body.classList.add("hide-text");   } } 

There is Pixel Density…

Ben Nadel recently blogged: Looking At How Browser Zoom Affects CSS Media Queries And Pixel-Density.

If you look at window.devicePixelRatio and zoom in, the pixel density in Chrome and Firefox will increase as you zoom in and decrease as you zoom out. Theoretically, you could test the original value (it might start at different places for users with different screens) and use changes in that value to guess zoom. But… in Safari it does nothing, as in, it stays the same regardless of zoom. Plus, the operating system zoom level can affect things here, making it extra tricky; not to mention that a page might start at a zoomed in level which could throw off the whole calculation from the start.

The post Can JavaScript Detect the Browser’s Zoom Level? appeared first on CSS-Tricks.


, , , ,

Zoom, CORS, and the Web

It’s sorta sad by funny that that big Zoom vulnerability thing was ultimately related to web technology and not really the app itself.

There is this idea of custom protocols or “URL schemes.” So, like gittower:// or dropbox:// or whatever. A native app can register them, then URLs that hit them get passed to the native app. iOS has “universal links” which are coming to the web apparently. (Atishay Jain has an excellent write-up on them.) But links like that don’t leave much choice — they will open in the app. If your app has both web and native components, you might want to offer the user a choice. So, you use a regular URL instead.

In order for that web page to open up a native app, apparently, the tactic used by many is to have it communicate with a server running on localhost on your own computer which uses a URL scheme to open the native app. Clever, but I’ve heard sentiment from folks like:

  • I had no idea this software was running a localhost server on my machine
  • It feels weird that websites out on the wild internet can communicate with my localhost server

That’s the way it is though. But there are some protections in place. Namely: CORS (Cross-Origin Resource Sharing). Ugh. I feel like I deal with some kind of CORS problem every week of my life. But it’s important. It prevents XHR requests from websites that aren’t specifically allowed. Imagine if you visit my website, and I have your browser shoot requests over to Facebook, hoping you are logged in so I can do things on your behalf. Bad. CORS doesn’t prevent that, the same-origin policy of browsers prevents that. CORS is the mechanism to control that.

If my website tries to communicate with your website, and your website’s response doesn’t have an Access-Control-Allow-Origin header with my domain or *, it will fail. But not everything is subject to CORS restrictions. Images, for example, are not. We can link up images from any domain and they will return data.

Chris Foster thinks CORS and a lack of understanding of CORS was at the heart of the Zoom bug.

Zoom may have needed to get this feature out and did not understand CORS. They couldn’t make the AJAX requests without the browser disallowing the attempt. Instead, they built this image hack to work around CORS. By doing this, they opened Zoom up to a big vulnerability because n/ot only can the Zoom website trigger operations in the native client and access the response, but every other website on the internet can too.

In the wake of all this, Nicolas Bailly wrote “What you should know about CORS”:

This is often a source of confusion for newcomers because it’s not immediately apparent what CORS is supposed to achieve. Firstly CORS is not a security measure in itself, it’s actually the opposite: CORS is a way to circumvent the “Same Origin Policy” which is the security measure preventing you from making [AJAX] requests to a different domain.

The post Zoom, CORS, and the Web appeared first on CSS-Tricks.