Revise NonBreakingSpaceOverride to use Georgia instead of base64 on the frontend

[allancole]

This change replaces the custom base64 “Hoefler Text”   character with that of Georgia in style.css to optimize the CSS on the front-end.

The base64 character is needed in the editor to maintain consistent line-heights and prevent text from getting truncated while typing. On the frontend these negative effects are virtually undetectable since the text is not editable, so Georgia can be used instead.

[kjellr]

I pushed 9fe2bf1, which fixes a small typo preventing this from kicking into action.

For the most part, this PR works fine. But it does does some weird things to the text position and width of text fields:

This shift occurs in both Chrome and Firefox for Mac. This may seem fixable, but it does make me a little nervous, especially at this late stage of the game. The current solution has no known bugs, and has been thoroughly tested. Before we change this again, I'd like to make sure we have a clear sense the issue is that we're aiming to solve. Are we trying to slim down the file size a little bit? Or is the problem just that we're using base64 encoding here, and that's hard to decipher?

We do have a separate, webfont version of the font that we could theoretically call instead. We originally tried this in aeb424f, but went with base64 encoding because the woff and woff2 file sizes are only 1kb and 764 bytes respectively. It seemed less performant to require a separate request for that file.

cc @jasmussen, @iseulde, since you were both involved in the original solution in #463

[jasmussen]

I share Kjell's concerns here — let's be very intentional about every change we make.

The base64 character is needed in the editor to maintain consistent line-heights and prevent text from getting truncated while typing. On the frontend these negative effects are virtually undetectable since the text is not editable, so Georgia can be used instead.

Can you elaborate a little bit on this?

Also, it might be good to mentally prepare ourselves for potentially looking at an alternative to Hoefler. What alternatives might work, if we keep encountering issues like these?

[allancole]

@jasmussen So, this was an alternate take on the base64 character solution for the frontend. It tries to lighten the CSS load and from what I understood, we needed to use the base64 solution in the editor to prevent text from getting clipped in text fields as mentioned here: #463 (comment).

Seemed like we could use the Georgia solution on the front end alone since it’s not the editor, but then as Kjell just pointed out there’s issues in the input fields and potentially other places which makes this a not so great approach.

Also, it might be good to mentally prepare ourselves for potentially looking at an alternative to Hoefler. What alternatives might work, if we keep encountering issues like these?

Replacing Hoefler Text isn’t off of the table but I’d prefer to revert back to the original base64 solution which is more reliable despite the one downside of a super long base64 string in our stylesheet. I also wonder if @iseulde might be able to help with this suggestion: #463 (comment)

It sounds like she’s suggesting something like this:

@font-face {
	font-family: 'NonBreakingSpaceOverride';
	src: local( 'Hoefler Text' );
	unicode-range: U+00A0;
}

I’m gonna try it out (may need to use a different unicode character), but if it checks out, this would be preferable over the base64 solution 👍

[allancole]

Nope that doesn’t work ^^ 😄

[ellatrix]

You'd still need to load a font with the character. Unfortunately there's no way to replace a character with another character of the same font. You need to replace it with the same character of a different font. So the only way is to use a local font or a font which contains just this one tile. Maybe there's ways to make the size smaller. It should be just one blank tile and some properties.

[ellatrix]

You can also just not fix it on the front-end?

[jasmussen]

There was an issue that needed a fix for the frontend, something with indented menus I think.

[allancole]

Gonna go ahead and close this since we’re now reverting back to the original base64 solution in #463, which is more reliable.