Bug with the |float filter when converting string to float

[SBurnett28]

Hi everyone,

I'm using a type scale to control responsive typography across a theme and to do this I need to perform calculations on a variable from the fields.json in the css/hubl file. In order to do this I need to convert the string value (say 1.414) into a float so I can actually use the math functions. Once I've done this ({% set typeScale = (value.from.json|float) %}) the resulting value is different between the page editor and the published page.

I have some screenshots here to explain what I'm seeing, but it looks like it's converting the decimal incorrectly? It takes 1.414 and turns it into 1414.0 in the page editor, but on the live page it is correct with 1.414. If I change the variable to 1,414 it does in fact convert the string to 1.414 with a decimal, but again on the live page it remains as 1,414. From what I understand, Java is supposed to be able to convert strings with decimals to their corresponding float correctly, and nowhere did I see in the Jinjava documentation that it wouldn't convert correctly either.

Live pageLive page devtoolsPage editorPage editor devtools

Edit: Thought I should add the code in my css file (pretend it says rem after typeScale on the line for font-size)

Code

What's even weirder, is if I DON'T convert it to float and write:

typeScale * typeScale * typeScale - it works,

but when I try:

typeScale ** 3 - it gives me a string error.

Wondering if I stumbled on a bug or not, if so, it's very frustrating because I'm sick of hardcoding font sizes.

[Gonzalo]

Hi there!

A few things may be happening here:

1. What you see in the editor may be broken. There is a reported bug that I found a few weeks ago, it only affects you if you use a lang in your HubSpot account that uses commas to split the numbers and dots for example Spanish: 1.500,25. This basically breaks everything when you try to add a float, it thinks you are setting the miles, and vice-versa. It doesn't work either way. So, double-check you have in your personal/account settings English for now.
   
   
2. The operator ** seems like it doesn't try to recognize the numbers as the basic math operator does (@Dennis, you may want to report this). For me the operation {{ "3.21"|float ** 3 }} does work. So I am assuming it's related to the first issue.

On a side note, you may want to jump into CSS variables, super recommended doing all of this, and much more, a lot of fun.
For your scalable font, you may want to search for the concept "fluid fonts". You can basically scale without breakpoints from mobile to desktop, with something like this:

body{
  --min-size: 16px;
  --max-size: 20px;
  font-size: clamp(var(--min-size), calc(var(--min-size) * 2vw), var(--max-size));
}

[SBurnett28]

Hi,

Thank you so much for responding.

1. I accidentally set my primary domain language as Dutch somehow which funnily enough does coincide with my calculations randomly breaking, as I could have sworn it worked properly before... If this is the case though, is there any indication that this will be fixed in the future? Since I can imagine someone, somewhere, at some point might also run into this and wonder what's happening. For now, I've worked around it by instead of doing "x|float ** 3" I just did "x * x * x" which works but looks hideous.

2.  You're probably right about this. It's been driving me nuts trying to figure out why I could multiply a string by a number but not square it and the only logical reason I could see was it was interpreting the string as a number correctly for the basic functions but not for the more advanced operators - not that I tried anything other than **. Mystery solved.

Yes, I have spent far too much time to be honest on the fluid typography train and my solution was to set a base font size in the theme settings alongside a type scale (so the 1.414 value was the augmented fourth type scale) and using that to calculate my minimum, clamp, and maximum values dynamically rather than setting the specific min/clamp/max sizes . I used the formula from this page to do it, substituting the min and max font sizes for calculations based on the type scale (so H1 max would be bodySize * (typeScale ** 4) for example, and I have calculations for every heading size). I wonder if you can tell I really want to get some use out of my engineering degree right now... I have a tendency to obsess over efficiency and automation sometimes.

[Gonzalo]

Hi @SBurnett28 ,

1. Then we can confirm it's related to the localization bug. It's reported and I would mark it as a high priority to be fixed, as HubSpot is doing a major effort to all the clients to migrate to themes which means that any client using a different language with a different number format is a broken experience I would say yes, it will be fixed (hopefully soon, @dennisedson can you check what's the status?).

Regarding your setup of fluid fonts... that was actually my very same first approach. I think it's the best way for the developers. Although, in the end, the client experience was somewhat confusing. I tried to explain several times and while most of the cases were in the end a successful education. I think it wasn't that great as I had to do the training for all the clients. This is fine if you have only one client (like, working on a company and implementing only there), but if you are for example an agency or freelance building a codebase where all your projects will be based on, like different themes for different clients, I personally swapped to a different approach to avoid friction on the client-side.

I ended up with theme settings that let the client set min and max sizes for the body and titles instead of based on a multiplier. This way the client knows right away what it means and how to use it. It's a bit more work on the dev side but ended up being a smoother experience for the client, and avoiding wasting extra time on documentation and education of the client.

[SBurnett28]

Glad this could be resolved, at least in the sense that I know what's going on. In the meantime I can keep using the basic math operator as a workaround and stick with the ugly code, it's not a huge deal. 

It's good to know I'm not the only one who tried to do this! I did consider your point about clients not understanding and so I added an option of adding your own font sizes with a boolean/checkbox and I would do the minimum calculation from there. In my current position no one seems to consider fluid type and instead just stick in arbitrary font sizes that aren't responsive. I felt that if I have to explain the entire concept of fluid type to begin with, I may as well explain type scales in the same go and what I've achieved within the theme settings.

Thank you so much for your time on this.

[dennisedson]

@Gonzalo , any chance you have seen something like this?