Mobile Auto Scale, not working

When I activated the mobile auto scale option, the mobile website start to behave in a strange way such as every thing got bigger, scroll location is missing up and getting to the middle of the page instead of top of page, I thought it was the layout blocks was the reason and spent time removing the layout blocks and rearranging everything until I discovered it was the mobile auto scaling option.

Through the hours of testing this I can let you know the following…

  • Auto-scaling does work a treat and gives a better visual on the larger mobile devices as elements are scaled up to work with the screen realestate
  • All the mobile browsers display auto-scaling well but not iOS Safari

To compensate for iOS Safari your text boxes should be around the 400px in height. The reason for this is that iOS Safari does not calculate the text in fractions like the other mobile browsers and so your long text boxes has the text height reducing leaving your layout with gaps - aka layout messes up.

If you are not making sense of what you are seeing and it is breaking your layout it would be best to discuss it with @duncan and send across your project file…

Thank you @FlaminFig for the reply, but the issue is mainly in the scroll location behavior, I can compensate how my text will look, but at lest when a link will be pressed it should go to the correct position.

Plus if iOS safari has an issue with Auto scaling, at least the server should load the mobile version without the scaling, right?

I am thinking to send the project file to @duncan but only after I finalize everything.

Yes there is an issue with scroll location positions vs. auto scaling on larger phones, it’s fixed in the upcoming 4.0.3.

1 Like

Only if you have asked Sparkle not to Mobile Auto-Scale.

So it sounds from what you are saying that although everything on mobile auto-scales that isn’t the case with the Scroll Location element. For now just taking a sample from your project highlighting the issue would be a big help for Duncan to identify what is going on…

Ok forget what I just said. Duncan is on to it! :slight_smile:

Duncan, will the 4.0.3 update solve the iOS issues that @FlaminFig describes?

No that’s a Safari bug, we can’t fix it. In practice it’s not a very visible issue most of the time, but if it does become one, we have the checkbox in the misc site settings to turn autoscaling off.

And just to be clear, the iOS Safari bug is that the text attributes of point size and line height will not scale to anything less than 200% (e.g., 110%, or 120%). Every other graphic element on the mobile layout scales properly.

Is that correct?

CC: @FlaminFig

The auto scaling uses a zoom factor like 1.25 or similar, but while coordinates of boxes end up falling on a pixel, text gets size is multiplied by the zoom factor so you get fractional pixels sizes.

The bug is that when the CSS specifies 14.5px or 14.25px, Safari will round it down to 14px. Chrome respects one decimal place, Firefox three.

The most likely reason for this is browser behavior is drawing text is computing intensive, so the bitmap of a drawn character is cached, but having many different character sizes means having a lot of memory dedicated to font caching, and that’s a problem particularly on mobile devices (particularly on older iPhones).

Anyway it’s been an open bug on WebKit for years, I’m not holding my breath for a fix.

I see.

So, whereas convention would have ≥ .5 round up, and ≤ .4 round down, Apple rounds all decimal values down for text size properties. (I assume they’d rather err on the side of not causing text to expand and blow out the structure of the page layout.)

Then, if the CSS specifies a scaled value of 14.5px for line height size, in Safari for iOS one would expect to lose 1px in overall paragraph height for every 2 lines of text. If 14 lines of text were set, one would lose 7px in overall paragraph height. If 28 lines of text were set, one would lose a full line height (14px) in overall paragraph height. Is that correct?

Yes that is what I experienced, and therefore I mentioned to keep your text box height to a minimum to reduce iOS Safari’s little tantrum glitch with its rounding off of it text sizing…

That makes sense.

Fortunately, most copy written for websites is short and to the point, and so the condensation of line height probably goes unnoticed.

If, for whatever reason, you’re setting a long text, perhaps it would be wise to assume a loss of 10% of overall paragraph height on iOS devices, and plan accordingly: either a) break up your long text into a series of text frame modules of limited depth, b) copy fit to a predetermined maximum text frame depth, where the variable white space below is acceptable for the design of your page, or c) turn off the auto-scaling for 320 mobile.

Kind of sucks to learn this. I’m shocked that a company like Apple, that has a reputation for design excellence, would allow this problem to persist.


@duncan The notes for the 4.0.3 update includes the following:

• fixed text scaling in auto-scaled devices

Does this fix the problem with iOS Safari not properly scaling text in the 320 layouts up?

No that was for some edge cases, the basic problem with iOS Safari can only be fixed by Apple.

This is the relevant webkit bug, which has been open since 2010:

1 Like

Okay. Thanks for the reply.

I guess Apple is too big to attend to these details. Consumed with bigger, “sexier” development problems.

As for website builders using Sparkle, I guess the best guidance is to leave the “Mobile auto-scaling” feature in the Site Settings disabled (unchecked). At least that way one can predict the correct rendering of text.

I don’t agree, the improvement is noticeable and very frequently there are minimal or barely visible side effects.


Okay. I’m glad to hear your confidence, and that the problem is very minor.

To better understand the implications of the Apple bug, I guess I should just do some of my own testing with representative page designs and various passages of text at different sizes.

You’ll find by shortening the text containers’ heights (as I mentioned earlier) would solve the problem.

But like you have mentioned testing is the way to find out and set yourself up for a better consistency across the 320 device.

1 Like


If you select Developer Tools - Responsive Design Mode on iMac and Safari, you can simulate iOS 14 on iPhone.

Does that give you a reliable result?
I have seen on some pages (iPhone view) that the text overflows and is cut off.

Mr. F.