Fluid sizes about pollen HOT 13 CLOSED

I've started incorporating this in my personal project. I initially thought that the naming convention was not to use dashes in the names of the individual values of the modules, but realised that the colors use them too --color-blue-500. So I guess that this makes sense for fluid values as well.

What I then did is to create fluid font scales like this:

--scale-fluid-000: 0.75rem;
--scale-fluid-00: clamp(var(--scale-00), 0.8rem + 0.25vw, var(--scale-0)) /* 30rem -> 80rem */;
--scale-fluid-0: clamp(var(--scale-0), 0.9464285714285714rem + 0.17857142857142858vw, var(--scale-1)) /* 30rem -> 100rem */;
--scale-fluid-1: clamp(var(--scale-1), 1.0714285714285714rem + 0.17857142857142858vw, var(--scale-2)) /* 30rem -> 100rem */;
--scale-fluid-2: clamp(var(--scale-2), 1.1428571428571428rem + 0.35714285714285715vw, var(--scale-3)) /* 30rem -> 100rem */;
--scale-fluid-3: clamp(var(--scale-3), 1.3392857142857142rem + 0.5357142857142857vw, var(--scale-4)) /* 30rem -> 100rem */;
--scale-fluid-4: clamp(var(--scale-4), 1.3928571428571428rem + 1.607142857142857vw, var(--scale-6)) /* 30rem -> 100rem */;
--scale-fluid-5: clamp(var(--scale-6), 2.357142857142857rem + 2.142857142857143vw, var(--scale-8)) /* 30rem -> 100rem */;
--scale-fluid-6: clamp(var(--scale-8), 3rem + 5vw, var(--scale-10)) /* 30rem -> 100rem */;

Of course they are generated with a helper function. But I quite like the idea that the fluid scales actually transition from the --scale- values. Of course, they are not really dynamic, because if you changed --scale-4 in the browser for example, then it would work insofar as that the max or min value in the clamp function would be correct, but the linear interpolation between the values would be a bit off (meaning: it would either reach the desired value too soon or too late).

So yeah. Not sure what to make of it. It adds quite the complex values so maybe it's just not worth it. It's also possible to just approximate the scaling and just add them manually. So instead of 2.357142857142857rem + 2.142857142857143vw we could just hard code 2.4rem + 2.2vw. No complicated generator functions and they scale approximately at the same speed. In my experience though, when resizing the browser window it looks pretty odd when the different sizes reach their "end destination" at different times...

What are your thoughts?

EDIT: I forgot to mention that there's also one more caveat: Because vw is always pixel based, and there is no way of getting it in rem the linear interpolation will only work with if 1rem is 16px. I guess that's fine though, since most UIs won't look that great with a bigger font anyway, so the fonts scaling at different speeds is going to be a minor problem.

from pollen.

I actually wrote a fairly popular postcss plug-in many years ago that implements this so I’m across the concept. Idk how it would fit into pollen though, even if you exported a function like that you couldn’t just apply it with a CSS variable, which breaks Pollens very straightforward abstraction.

EDIT — okay so I totally misread your issue and wasn’t aware of the clamp function. Sounds like there’s definitely a viable approach to explore there! One approach would be to export some useful utility functions like you mentioned that users could use in config (generating font typesets is another use case for a handy util function for eg), but I’m wary of adding more API surface unless we have to

from pollen.

@madeleineostoja oh that's great. The plugin looks really interesting.

I completely agree that adding more API surface needs to be done thoughtfully, but I think that adding some kind of fluid system could be worth it.

With a clamp function it can just be limited to a single custom property. If you're worried about exposing a function to do this, maybe an approach would be to add fluid font sizes in a first step without exposing the JS function that allows generating them? ... but then again it's annoying that a user can't easily change the values... mmmh.

In any case, this is what I have used so far:

const breakpoints = {
  xs: 480,
  sm: 640,
  md: 768,
  lg: 1024,
  xl: 1280,
  "2xl": 1600,
}

const linearClamp = (minWidth, maxWidth, minSize, maxSize) => {
  minWidth = breakpoints[minWidth] ?? parseFloat(minWidth)
  maxWidth = breakpoints[maxWidth] ?? parseFloat(maxWidth)
  minSize = parseFloat(minSize)
  maxSize = parseFloat(maxSize)

  const slope = (maxSize - minSize) / (maxWidth - minWidth)
  const yAxisIntersection = -minWidth * slope + minSize
  const preferredValue = `${yAxisIntersection}rem + ${slope * 100}vw`

  return `clamp(${minSize}rem, ${preferredValue}, ${maxSize}rem)`
}

Ideally the breakpoints could be reused from the --width-* properties. Any ideas on that?

EDIT: My initial thought was, that I could just write this function in CSS. This would be really awesome, because then you could simply use --scale-2 and --width-xs (for example) to calculate the fluid sizes. But that's not possible because you can't divide by dimensions in CSS...

I then thought, that it would be possible to simply define the scale and width, etc... as simple numbers like this:

--raw--scale-2: 1.25;
/* ... */
--raw--width-sm: 640;
/* ... */

--scale-2: var(--raw--scale-2) * 1rem;
--width-sm: var(--raw--width-sm) * 1px;

Then you could use these "raw" values to do the calculation easily while still using the same variable. But I just abandoned this approach because it makes everything so complicated. And I think that for pollen it would be really confusing for new users.

from pollen.

Thanks for the examples! Yeah I agree that it wouldn't be worth changing how fundamentals like the size and width scales work, it would make Pollen as a whole very complicated for one niche feature.

I think finding a compromise between 'perfect' fluid units and something straightforward would be the best approach. Sounds like generating defaults with some JS and just giving those to the user could be that compromise. We can reuse variables from config by just stripping units with regex in any js logic needed

from pollen.

As an aside if we did implement this the new fluid scale should largely mirror the existing font scale, just tween values based on viewport

from pollen.

As an aside if we did implement this the new fluid scale should largely mirror the existing font scale, just tween values based on viewport

Yes agreed. I think that in general, the font sizes are very typical at about 1024px width, and tend to normalise a bit on smaller devices and "grow apart" on larger devices.

I'm just think about how this could be introduced. Because it doesn't only affect the font sizes, you'd also want the line-heights to be fluid I guess?

So, maybe a very trivial approach would be to add --fluidline-xs...xl and --fluidscale-0...10 (or maybe --fline and --fscale, or even: --line-fluidxs and --scale-fluid0)?

Then all these values would be available, and everyone could simply define their display and text defaults?

from pollen.

Line heights are unitless so you wouldn't need those to be fluid to maintain a proportionate fluid scale

from pollen.

Line heights are unitless so you wouldn't need those to be fluid to maintain a proportionate fluid scale

That is true, but still line heights change depending on size sometimes. Like in heybokeh/design

But yeah.. maybe that's exaggerated.

from pollen.

They’re just typesets, not bound to viewport sizes

from pollen.

Yes, but if you create fluid typesets, then the line heights would possibly be fluid as well, since it's pretty common to reduce the line height for bigger fonts in titles and vice versa. But as I said, that is probably overkill.

If you want, I can start on a PR to introduce some basic fluid scales, and we can continue iterating in a PR?

If so, what naming convention would you go for?

1. --scale-fluid0
2. --scale-0fluid
3. --scale-f0
4. --scale-0f
5. --fluidscale-0

from pollen.

Looks great! I agree it might be worth just hard-coding rounded values, saves a bunch of complexity at (from what I understand) a very minor cost. Can always add a helper function later if people feel it would add value. Love that its just essentially tweening between values on the font scale 🙌🏼

In terms of naming, I think just simple --fluid-[x] could be quite nice too. Tradeoff between explicitness and terseness. Would be good to get some feedback from others on naming of it.

And yep the current font size scale assumes a 16px root font size. If someone has changed the root font size (anti pattern to do so these days anyway) that isn't accounted for by Pollen's defaults, and they'd have to define custom scales anyway.

from pollen.

Glad you like it!

Yes I agree. After the short discussion with you, I read up on it and came to the same conclusion. It's not even possible to change the default font size in Safari.

I think --fluid-[x] sounds good, but it might be confusing that this is referring to fluid font sizes. Because it would/could make sense to also offer fluid pixel sizes (for example, I always like my content paddings to be a bit larger/smaller depending on screen size)

from pollen.

To add to this, I think an advantage of using --scale-fluid-[x] and --size-fluid-[x] would be that they are more easily discoverable.

I was also thinking, whether it would make sense to make them more easily recognisable to actually use the value names as well. So for example, if there is a fluid value from 0 to 1 then it could be: --scale-fluid-0-1 or even simply --scale-0-1. I like this quite a bit, because it's a lot clearer what they represent.

Edit: It would also make it very easy and clear to add new values for users of pollen. Don't find the fluid scale you're looking for? Just create a --scale-[x]-[y] yourself and set the value and it fits right in with the naming convention.

from pollen.