Scaling components via font size

[danielchalmers]

Problem

Some component libraries have a Size property that scales the component using manual inputs, usually pixels, but I recently worked on overhauling a component to scale via relative units and thought I should put the idea out there!

PureBlazor uses relative units all over the place, which is awesome, but they are typically rem which means you can't freely scale up a component.

Demonstration

Here are some videos of me changing the font-size of a component (not the text):

https://github.com/pureblazor/components/assets/7112040/4eaa1f7b-c87b-4679-9bcb-b4d144367c98

https://github.com/pureblazor/components/assets/7112040/c09b93c2-d785-4ffe-b2fa-91303b220c0e

https://github.com/pureblazor/components/assets/7112040/1ae0c5c0-4d1b-4a43-bb36-71383862b009

The icons and margins don't scale with the font size.

Suggestion

There isn't necessarily a right or wrong way of doing this, but there is some utility in being able to scale up a component to your own size. This might remove the need for a custom sizing system altogether and thus pre-emptively simplify the code.

You could replace some cases of rem with em and make the icons scale.

Mock-up:

https://github.com/pureblazor/components/assets/7112040/6ed53152-f895-4e91-9887-cb8531676ea4

[codymullins]

interesting. related: https://github.com/tailwindlabs/tailwindcss/discussions/3105

[codymullins]

I've been thinking about this quite a bit, primarily around the upsides vs the downsides here.

The upside is clear - as you have documented. Automatically scaling padding by just changing the font size is nice, and does provide a nice dev loop of not having to worry about changing the size of buttons.

On the other hand, em is slightly more "inconsistent", where rem feels more predictable. With that said, I think rem is still the preferred default for me.

We can still support this in the following ways:

Targeted Component Changes Some components, such as badges and banners, may be perfect candidates to use em over rem. This feels safe. Other components, such as buttons and inputs, may be a bit too wonky to default to em.

Existing Styles Parameter Styles can be overridden to use em style padding over rem style padding for one-offs. I'm not sure if this case is covered in the CssExtractor yet by default. We'd likely want to add our own em style padding class here.

Custom Global Style Since this library is Tailwind based, users can completely override the styles of the buttons and have all (or some) use em.

What do you think? Are there certain scenarios you see this scaling being helpful?

[danielchalmers]

Great points. It's subjective and it does make sense to have consistently sized buttons etc.

1. It depends on how you want to provide sizing. Most give you a Size enum with {Small, Medium, Large}, but what do you do if you want it larger than Large? You can set the height yourself but the text, adornments, icons, etc will stay the same. With em you can scale it: 100%, 75%, 125%, etc.

2. It complicates the design process in the way that you have to define values for each part for each size instead of scaling it all naturally.

3. More flexibility: If they want to stick with rem they can, but they can't use em if the styles explicitly use rem.

A lot to consider which is why I wanted to bring it up :)

[codymullins]

@danielchalmers any interest in doing a small proof of concept?

[danielchalmers]

I will have more time in Aug to set something up