Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Annotator control UI is affected by base-REM changes in host page #4248

Closed
lyzadanger opened this issue Feb 25, 2022 · 1 comment · Fixed by #4278
Closed

Annotator control UI is affected by base-REM changes in host page #4248

lyzadanger opened this issue Feb 25, 2022 · 1 comment · Fixed by #4278
Assignees

Comments

@lyzadanger
Copy link
Contributor

We've run into a few cases in which user font-zooming (which resets the base REM size) or host page REM base sizing detrimentally affects the UI of the controls in the annotator (those controls rendered inside of shadow DOMs in the host page).

In the most pertinent case of VitalSource EPUB support, zooming the font size in the VitalSource viewer is impacting the layout and appearance of the toolbar buttons next to the sidebar:

image

We need to decide whether we want to:

  • Allow these controls to scale with user scaling (grow and shrink) with the host page's base font size. In this case, we need to make all of the applied CSS relative. Right now we have a mix of relative spacing/sizing with absolute (pixel) font sizes. The spacing is scaling but the fonts are not, and there may be some remaining pixel-based positioning that breaks down.
  • Enforce an absolute size for these controls no matter what user scaling preference is. In this case, we need to make all of the applied CSS absolute.

My heart prefers the first option because it is truer to the web's intention and feels more accessible. However, there may be general preference for the second. I'm going to need some input.

See also a related case in PDFjs from a few weeks ago: #4208

@chrisshaw
Copy link

Strongly in favor of the first option for the accessibility reason @lyzadanger describes. This is an often explicit recommendation by accessibility advocates.

This particular problem doesn't look urgent, but if we find a collection of places where user preference breaks our design then it may be high time to change our design to accommodate it.

lyzadanger added a commit that referenced this issue Feb 25, 2022
Add a couple of test HTML documents in the local dev server that
demonstrate how the client renders in situations where the host page's
root font size is set tiny (10px) or huge (24px).

These test pages will help with solving
#4248
lyzadanger added a commit that referenced this issue Feb 28, 2022
Add a couple of test HTML documents in the local dev server that
demonstrate how the client renders in situations where the host page's
root font size is set tiny (10px) or huge (24px).

These test pages will help with solving
#4248
@lyzadanger lyzadanger self-assigned this Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants