styling issue with Webchat due to the font-size being set to 62.5%

[sakukreti]

Hi team, I have a customer who is encountering a styling issue with Webchat due to the font-size being set to 62.5% on one of the pages the Webchat-Widget is included in.
They are using Twilio-Paste Components and cannot change the font-size to 100% as that would break the rest of a page. Do you have a solution to accommodate for that or documentation that would help us fix it?

PS: Setting font-size to 62.5% in the html tag is a popular trick to ease the styling using rem values: https://www.toheeb.com/en/pages/62.5-font-size-trick/
They are using https://github.com/twilio/twilio-webchat-react-app/ as base repo

To give some visual context here...When they open the chat bubble and the webchat app is visible, the page change the size of its components. If they open the bubble when customer is logged in (another page), in this case the page is ok but the chat elements are too little. Sometimes it's changing the page style and some others the webchat ones. Must be something in between that is causing this issue

[nkrantz]

Hi @sakukreti - we're taking a look at this today and we'll get back to you soon with an update. Thanks!

[SiTaggart]

Hi @sakukreti

To be able to correctly set proportionally sized spacing, sizing and typography based on the users personal preference, we have to rely on a percentage font-size set on the html element. We do this for accessibility reasons.

There are two schools of thought, those who set the base font size to 100% (16px) and those who set the base font size to 62.5% (10px). Neither are wrong, they work in exactly the same way. But we had to pick one, and we predominantly saw 100% being set on the applications we were targeting. Unfortunately, that doesn't work in this case.

I think ultimately the only thing we can do is add a new design token for base font size. A consumer could then override the base font size token, and font-size tokens to match their application's needs, so Paste doesn't clash.

I can't say when we'd get to that, though, at the moment, as we're in the midst of closing out Q1 right now. We'll come back and update when we've gotten it triaged.

[espipj]

Hello related with this issue. We've been investigating on the webchat ui side and it seems that Paste is adding styles on the body itself whenever you add a styles provider in your app (in this case the webchat). One of those styles is related to the fonts sizing. is this expected? If so, is there any workaround to override those global styles/remove them customer side?

[sakukreti]

@oscar8880 the customer tried the workaround but it did not work, they suspect we dont see the same issue in Codesanbox because it does not have any <style data-emotion="css-global" data-s=""></style> tag included.

[oscar8880]

@sakukreti

Checking the source of the code sandbox I do see the <style data-emotion="css-global" data-s=""></style> tag:
. I'm not convinced that this is necessarily related to the issue.

Could you share how the customer is overriding the fontSize30 token so we can verify that they're doing that correctly?

I would expect them to be adding the override either:

• directly where we use the CustomizationProvider in the code in src/components/WebchatWidget.tsx, e.g on line 35:
  theme={{ ...theme?.overrides, fontSizes: { fontSize30: "16px" } }}
• or in config which is passed to the initWebchat function in public/index.html:

Twilio.initWebchat({
	serverUrl: "%REACT_APP_SERVER_URL%",
	theme: {
		isLight: true,
		overrides : {
			fontSizes: {
				fontSize30: "16px"
			}
		}
	}

[SiTaggart]

We might need both, the new token for setting the html element font size and move setting the base font size from the body element back to the Theme.Provider and CustomizationProvider div (where it used to be a couple of years ago).

It's the closest to style encapsulation as we can get without a shadow root or iframe, given CSS is close and inherits.

[oscar8880]

That's true! Is there a way we can track progress on those two pieces of work?

[SiTaggart]

Hi folks, this is now released

[sakukreti]

@oscar8880 @SiTaggart The customer tried all our suggestions, however, they didn't work/were not enough.
In the end they created a custom theme that overrides all Twilio-Paste styling fields that use rem, with a new rem value, that fits to their 62.5% base (e.g. 1 rem became 1.6rem).
To stop webchat from increasing the base font-size for the whole page, they contacted the host page and asked them to add a '!important' to their font-size. For now, it seems like they managed to work around all Twilio-Paste related issues.

[SiTaggart]

Hi, you can follow along on progress here #3090

[SiTaggart]

This is now released and available to install with the latest version of Paste Core.

[sakukreti]

@SiTaggart The customer tried out the latest Paste package and do not see any results.

Steps taken:

1. Update Twilio Paste packages to latest versions:
   a. @twilio-paste/core : 19.0.0,
   b. /icons to 11.0.0
   c. and /theme to 10.0.0

2. Override fontSizeBase token:
   a. Exactly as suggested in discussion here:
   b. theme={{ ...theme?.overrides, fontSizes: { fontSizeBase: '62.5%' }}}
   i. in
   c. fontSizeBase is properly recognised as a token after the update

3. Tried different values for the fontSizeBase:
   a. 62.5%
   b. 62.5% !important
   c. 10px
   d. 10px !important

None of the tested values yielded any results or made any difference, the styling issue persisted.

[SiTaggart]

My mistake, onece this PR is merged, then it'll be available to install. Hang in there #3126

[SiTaggart]

I actually mis-spoke about getting it wrong. It is in Paste 19.

Here is a Codesandbox showing using an existing style sheet which sets the html element to 62.5%, and then customizing the Paste theme to honor that setting. https://codesandbox.io/s/base-font-size-overrides-hewmpd?file=/public/index.html

[sakukreti]

@SiTaggart the customer tried the latest solution (#3064 (reply in thread)) and it's working fine with the Codesanbox example provided but they were under the impression that they only have to change the fontSizeBase and internally Paste will handle/calculate the sizes taking into account the percentage of the font size base, that way they can get rid of the custom theme.
But actually they have to do the same that they were doing with the custom theme, adding the fontSizeBase and update all values and are unsure if its worth the effort to change it.
Do you have any recommendations?

[SiTaggart]

Hi @sakukreti

No, that was never going to be the case unfortunately, based on the fact the Paste uses proportional sizing for spacing and typography, which is influenced by the HTML font size.

This solution, although a little more manual, gives full control over to the implementor as we can't tell what it should be as we can't see the application it's being added to.