Font-size/zoom issues on iPadOS (desktop-class) + Firefox

[JayPanoz]

So this was supposed to be resolved through #155 but it looks like things have broken in nasty ways ever since.

We have two major issues with the new implementation of font-size (relying on zoom):

• -webkit-text-size-adjust: none seems to not disable iPadOS desktop-class interventions reliably any longer;
• Firefox implementation seems to really struggle inheriting zoom when there is a wrapping div/section, and has some nasty bugs on top of it.

From testing and debugging from the problematic files on Readium Playground.

Moby Dick:

• Firefox → zoom: inherit on body > section is needed to make it work, as well as disabling the font-family in… a Media Query (WTH)
• Firefox → when removing font-family on body and from the Media Query for p that works as expected without inheriting
• Safari iPadOS in desktop mode requires disabling the font-family in the Media Query as well

Les diaboliques:

• Firefox: zoom: inherit on body > div seems to be fixing at least most of the issues
• Firefox → when removing font-family on body that works as expected without inheriting
• Safari iPadOS → i, span, etc. must have zoom: value set directly. Disabling the publisher font-family doesn’t seem to have any positive effect.

It makes things quite possibly impossible to handle from ReadiumCSS, since adding zoom:inherit is basically like applying it twice in the cascade for other browsers. Same when setting it on elements.

[JayPanoz]

More on Firefox:

When applying one of our font-family, zoom is broken as well, but if changing value inherit to revert in the font-family submodule, it works as expected.

Edit: switched to revert in latest develop version (beta-9) as it hasn’t proved problematic.

[JayPanoz]

Firefox should be fixed in beta-10. Luckily, it works as expected when setting :root to 1rem instead of 100% because font-family breaks zoom when set on an element when font-size is unset or inherited from percentage, em, etc.

Will create a test case and open a bug report for this cos’ it’s quite uncomfortable having this tied entirely to the unit we are using.

Safari iPadOS + desktop website is a whole other issue though, cos the implementation of the zoom intervention is so fundamentally broken the most reliable way to handle it is having the mobile website requested. I’ve had to do a lot of testing and debugging to isolate all the issues to solve in the first place, then find if they are solvable.

The fun part being these interventions for desktop-class experience are not part of Webkit per se, they are Apple 100%, so even if reporting that in their bug tracker, I’m not sure it will be addressed.

[JayPanoz]

OK so Safari iOS with desktop-class experience can in theory be resolved using the combination of:

• -webkit-text-size-adjust: none
• -webkit-text-zoom: reset | normal

The major issue is that the value for -webkit-text-zoom depends on context e.g. you don’t want to reset within another reset (e.g. span in p), which makes it super complex to handle as you end up with very convoluted selectors to cover all cases. This is probably also why their intervention is so broken in the first place.

Once again for some reason font-family seems to throw sand in the gears, which is why -webkit-text-zoom has to be used.

I can attempt to create a patch for iPadOS + desktop cos it makes me very uncomfortable to add that into the font-size user setting submodule tbh. But that has the potential to become high effort high maintenance in the longer term.

[JayPanoz]

• demo for Firefox bug
• Bugzilla ticket

[JayPanoz]

iPadOS:

The following screenshot demonstrates how broken text-size-adjust actually is, as only normal text in p will be zoomed properly. Headings (h1) and even span and i are not.

You can make it kinda work with -webkit-text-zoom on these elements, but it will be a painful one.

[JayPanoz]

• Demo Pen for iPadOS.
• Issue

With a screencap for people who don’t have an iPad:

[JayPanoz]

Interestingly enough, normalizing text makes it work as expected so it seems Safari on iPadOS is struggling with font properties here (font-style, font-weight, font-variant…)

Currently in the process of writing a patch, using -webkit-text-zoom to get around the issue, which is kinda tricky and will be high maintenance since the selectors have to be fined-tuned quite a lot and I’m expecting edge cases to pop up with the increasing number of publications we need to handle.