Default values in px and zoom are conflicting

[qnga]

Describe the bug

Some Readium CSS variables have default values in px in case they're not set. This is the case, for instance, of --RS__defaultLineLength. As this property is translated into a CSS property whose values must be in the zoomed coordinated system, setting a --USER__fontSize different of 1 leads to inconsistent (and bad) effective values.

How to reproduce?

1. Use the scroll mode.
2. Do not set --RS__defaultLineLength or --USER__lineLength so that the default value applies.
3. Change --USER__fontSize to 0.1. If your viewport is large enough, you'll see margins far bigger than with --USER__fontSize == 1 because line length is limited to 640px in the zoomed coordinate system instead of the original one.

Readium CSS version

2.0.0-beta.13

Platforms

Android

Browsers

Android System WebView

Additional context

No response

[JayPanoz]

Note to self.

In practice I'll have to review any unit impacted by zoom, so that includes vh, vw, etc. In body scope. We know from Thorium Desktop's experience they are being scaled.

I can think of safeguard for img already.

But of course these are just the values from ReadiumCSS, the ones from authors are another issue entirely.

[JayPanoz]

List of impacted styles:

• css/css/vars/pagination.json

  Line 5 in 0a8f564

  "RS__defaultLineLength": "40rem",

• css/css/src/modules/ReadiumCSS-pagination-vertical.css

  Line 90 in 0a8f564

  max-height: var(--RS__defaultLineLength) !important;

• css/css/src/modules/ReadiumCSS-pagination.css

  Line 76 in 0a8f564

  max-width: var(--RS__defaultLineLength) !important;

• css/css/src/modules/ReadiumCSS-safeguards-vertical.css

  Line 16 in 0a8f564

  --RS__maxMediaHeight: 100vw;

• css/css/src/modules/ReadiumCSS-safeguards.css

  Line 17 in 0a8f564

  --RS__maxMediaHeight: 95vh;

• css/css/src/modules/ReadiumCSS-scroll-vertical.css

  Line 28 in 0a8f564

  max-width: var(--RS__defaultLineLength) !important;

• css/css/src/modules/ReadiumCSS-scroll.css

  Line 27 in 0a8f564

  max-width: var(--RS__defaultLineLength) !important;

Impact is seemingly limited – although I‘ll probably make a second pass to make sure the list is exhaustive.

Limited impact does not mean it will be easy to resolve though. If anything, the json vars can only be imported as a whole so the default max-width would have to be removed from it if we go the route of calc() taking zoom factor into account. Or we need a custom PostCSS plugin… Or we remove it entirely but that means text will always be the width of the column if you do not set lineLength.

For viewport units, I do not see any other solution than factoring in zoom, with the added complexity of non-support + opting in the deprecated implementation.

[JayPanoz]

Resolution:

• defaultLineLength is removed – or at least it becomes 100% through UA styles
• we will try compensating viewport units – but needs checking in browsers for confirmation it should work

[JayPanoz]

Ah yes of course, Safari has decided to do the proper thing with viewport units while Chrome and Firefox have decided to scale them… so for the safeguard I cannot just compensate the max-height|width. Great!

Safari:

Chrome:

Firefox:

[JayPanoz]

Right so I am afraid I am not able to solve viewport units in safeguards at the moment.

Webkit is manageable, although it relies on CSS tricks to sniff Webkit… and we try not to do that.

What isn’t, is the zoom should be set as percentage because of the iOSPatch, and you cannot divide by a non-unitless value in calc(). Well, there is a behavioural update but I cannot get it to work for our use case, it simply sets the computed value as 0.

So I’ll need more R&D allocated to this, and will split the issue into two PRs. One removing the --RS__defaultLineLength and another one attempting to solve the safeguard conundrum.