-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fluid sizes #73
Comments
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 |
@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 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 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 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. |
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 |
As an aside if we did implement this the new |
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 Then all these values would be available, and everyone could simply define their |
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 But yeah.. maybe that's exaggerated. |
They’re just typesets, not bound to viewport sizes |
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?
|
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 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 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 What are your thoughts? EDIT: I forgot to mention that there's also one more caveat: Because |
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 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. |
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 |
To add to this, I think an advantage of using 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 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 |
I've been using Pollen for the last 2 weeks and it's amazing.
I think that one addition that would be nice is a fluid sizing system. I've seen the same in Open Props although I think that their implementation is not great.
I know that I can configure fluid sizes myself, but it would be really great to have them out of the box since I think this is a good pattern that should be encouraged.
The Open Props implementation is very simple:
but I think that this is too simple, since this means that fonts will shrink at different speeds and reach their min and max at different viewport widths.
What I have been using is based on this css-tricks article and it works perfectly. The downside with this method is, that it's not possible to use the
--scale-X
custom properties in CSS because it involves doing some math that can't be done with<dimension>
types.I'm not 100% sure how to solve this best, but one suggestion would be to add a
linearClamp
function that takes a viewport min and max width in px and a size min and max in rem and spits out theclamp([...])
property. This can then be used to generate the default values inpollen.css
but also by users of the library to generate their own fluid sizes.What do you think? If you like this idea I can create a PR to discuss this further.
The text was updated successfully, but these errors were encountered: