Deprecating the @font-size-base colorTheme variable

Development
#1

Following the comment of @MichaelHamann on a recent PR, I want to open a discussion about our strategy moving forward regarding the base font size we use on XWiki.

Until now, following the strategy introduced in bootstrap, the base-font-size was a pixel value, by default 10px. This is nice for admins, which can change the font-size in the color theme edit interface, and be sure that every user will get the exact same interface.
However, since at least version 102 of Firefox (June 2022), before 2020 for Chromium, and even earlier for Safari, there is a browser level setting for font-size.
I think it would make sense to remove the parameter @font-base-size from the color theme interface and use the browser level user preference as a base instead.

Of course this would improve responsiveness for most content, but not everything. We would need to slowly replace the references to @base-font-size in the skin with rem units or percentage to provide a fully zoomable and user responsive UI. In the middle of the process, the default interface will still look okay but some elements might be disproportioned for users with non-default font-size settings.
Here is the view with a very basic replacement of the variable, for a user which base font-size is 22px instead of the default 16px:
image
For example we can see in the xwiki header that the bell icon is larger than its neighbors.
More examples and easier comparison can be found on this message.

In my opinion, this change is positive for the average User experience, and do not remove a very useful customization option from Administrators, so I’m in favor of it.

Do you agree with the removal of @font-base-size from the color theme to instead rely on user defined preferences?

Thank you for your interest in this topic!
Lucas C.

#2

Hi Lucas.

I’m ok on the idea to honor the browser font size. Now I’m not sure to understand the issue with browser font sizes. I’ve tested on 15.10.5 and I can increase or decrease the font size in the browser and XWiki reacts accordingly.

However we need a migration strategy that doesn’t generate some discrepancies in the UI (they would be seen as bugs). Also, we need to preserve backward-compatibility since a lot of users will have used it in their custom theme or elsewhere, ie. if @base-font-size is used, then we should honor it (and probably only use the browser font size when it’s not used).

Thanks!

#3

For reference, here are a few screenshots to demonstrate the issue on a 16.1.0-SNAPSHOT standard flavor distribution.
First, I go in my browser (Firefox) settings and change the default font size from 16px to 30px.
IncreasedFontSize
Then I check two websites:

  1. Reload without cache of XWiki, no change visible on the UI (when looking at why, that’s because bootstrap sets the default size of the doc to 10px or the value of @base-font-size).
    IncreasedFontSize2
  2. Reload this forum (works on a lot more pages). We can see that the text is way bigger than it uses to be and actually respects the 30px default font size.
    increasedFontSize

I think removing the UI and adding a warning (with appropriate alternative solutions) in the doc is a good first step for this process. This way, users and developers will rely on it less and less and we can promote the creation of accessible UIs.
The second step would be to remove the dependencies on this variable in xwiki-platform. E.g. compute title size by using native CSS functionalities (rem units and percentages) instead of relying on this variable. This way, the whole XWiki UI will become responsive to the user font-size preference. We want to avoid disrepancies in the UI, so we should fix all of them in the same version (so probably as part of the fix for the same ticket). Note that with a default font-size, there isn’t any disrepancies, except for font-size that already did not rely on this variable. One issue I see left with this process is that extensions which did use percentage and rems for font-size before will have the basis of those units changed from the hard-coded 10px to the user default 16px. For example, see the changes I had to make in this commit. I was using percentages, and the 160% didn’t compute to the same final value, which did create an unexpected change in UI. I had to change the 160% back to 100% to match the new base.

Along this process, the variable is still here, it’s just less convenient to edit it and its use is discouraged. This way, no style gets broken and we can safely transition towards a user responsive interface.

Thanks for your feedback!
Lucas

#4

I think we should aim to respect the font size that has been set in the browser. However, I fear we’re not there yet, and it is quite some work to get there.

What I mean by this is that as screenshots like the following (provided in the pull request) show, not all content follows the chosen font size. Not even all text, there is a lot of important text that remains unreadable small:

image

And this screenshot doesn’t even show more advanced UI elements like the WYSIWYG editor, tabs, Livetable, Live Data, …

To properly support different font sizes we need to make sure that:

  • All font sizes are relatively smaller/larger than the chosen font size.
  • Icon and button size is increased consistently
  • Spacing is scaled, too - this doesn’t need to be linear, but, e.g., icons shouldn’t overlap with text.

As long as these conditions aren’t fulfilled at least in most cases, I think we should keep @font-size-base and users that want a larger font size need to rely on zooming the whole webpage in the browser (I think this is what @vmassol tested). The reason for this is that I think it is worse to half-respect the font size that is set by the user than to ignore it. In the current state, the user can zoom and then have a consistent, larger UI. Browsers remember zoom levels per domain in my experience, so I think this is not too bad. However, with the proposed solution, this no longer works as none of the overlaps and discrepancies in font size can be fixed by zooming in. The only fix for the user would be to undo the font size preference in the browser - and for this the user would also need to understand first that this is the issue and XWiki doesn’t just use such a strange design.

For the very same reason, I’m also against creating a new user preference for font size in the current state as it just gives a false promise - it promises to make everything more readable while in reality it only makes some text more readable and at the same time breaks the overall design.

What I would suggest instead is to create guidelines that we need to follow to achieve the goal of having a UI that nicely responds to font size changes. Like guidelines for:

  • How do we define spacing?
  • How do you get the size of an icon or button?
  • Which font sizes do we use?
  • How do we scale panels, how do we define “breakpoints” when we stop displaying panels next to the content etc.

I suggest that we try to

  1. Define such guidelines or adopt existing guidelines
  2. Follow these guidelines for any new code and for the UI revamps that we’re doing at the moment.
  3. Plan some time for applying the guidelines to the main UI elements.

Once we’re following these guidelines in most places and the UI looks nice on a wide range of font sizes, we can discuss again introducing a font size setting and respect the font size set in the browser.

1 Like
#5

yes, the way I tested was with “view” > “zoom in” or “zoom out” in Chrome, and the font size was adjusted. It’s probably relative to the font size chosen by XWiki.

#6

IMO the hardest to define and implement will be the first one (spacing).
The size of a button depends on how we define spacing around its content, the size of an icon might change depending on the icon type (img vs font).
The panel breakpoints are too specific to be the subject of a guideline.

:+1: , and not using the @font-size-base might be one of those guidelines.

#7

What I mean is that currently, all media queries, e.g., for deciding if we have enough space for panels for example, are based on pixel sizes. However, when we allow a dynamic font size, this could mean that there is a lot less space for content on the screen. So I’m wondering, should these breakpoints also depend on the font size?

#8

I just found out about The Surprising Truth About Pixels and Accessibility: should I use pixels or rems? which gives interesting tips on what kind of length unit should be used in what context and confirms what we said above about accessibility. This can be a baseline for defining some guidelines :slight_smile:

#9

Here is a recent article from a web accessibility specialist supporting the idea behind this proposal:
https://adrianroselli.com/2024/03/the-ultimate-ideal-bestest-base-font-size-that-everyone-is-keeping-a-secret-especially-chet.html

:slight_smile: