Skip to content
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

Should $hu-opacity-types and $hu-scale-types use percentages instead of scales? #33

Open
stowball opened this issue Aug 3, 2020 · 8 comments
Labels
breaking change question Further information is requested

Comments

@stowball
Copy link
Owner

stowball commented Aug 3, 2020

Currently, $hu-opacity-types and $hu-scale-types use scale values like 50: 0.5, but should they use percentages like 50%: 0.5 like width etc? Would that be clearer?

@stowball stowball added question Further information is requested breaking change labels Aug 3, 2020
@joeldbirch
Copy link
Contributor

I think I prefer the unitless scales, which in this case (and other cases) map to something that does not use % in CSS. Width values are different. Not only do they actually use % for percentages, but they can also take other units, making the use of % meaningful.

@stowball
Copy link
Owner Author

stowball commented Aug 3, 2020

Width values are different. Not only do they actually use % for percentages, but they can also take other units, making the use of % meaningful.

🤔 That's an interesting point.

However, as a counter-point, do the unitless scales more represent something that isn't sequential, or doesn't have a near 1:1 mapping?

When I think of opacity, I always think in percentages ("can you make that 50% opacity?"), and often get annoyed that CSS represents it in 0 - 1.

The same is true for scaling. "Can you make that 50% smaller?" instead of 0.5.

@joeldbirch
Copy link
Contributor

I’m not yet convinced on this either way, but to add another thing: would it be right to punish people for “correctly” remembering that opacity/scale values are not percentage-based?

Also, would an entirely accurate opacity:0.5 not be a valid and possibly stronger option?

@stowball
Copy link
Owner Author

stowball commented Aug 3, 2020

would an entirely accurate opacity:0.5 not be a valid and possibly stronger option?

Definitely more valid, but I don't like it 🤣

@joeldbirch
Copy link
Contributor

Fair enough. But “going rogue” and making up stuff runs the risk of straying from what makes Hucssley so refreshingly predictable.

@stowball
Copy link
Owner Author

stowball commented Aug 4, 2020

making up stuff runs the risk of straying from what makes Hucssley so refreshingly predictable.

😭

Perhaps these types of values are more likely to be customised to suit your design system, so using a scale may help to reiterate that?

Just looking at Material Design, and it's totally plausible that you would change the scales to only the allowed values in your system
image

@joeldbirch
Copy link
Contributor

Good point, that's a valid use of a scale. It may get a bit confusing that the current scale looks like "it's just a regular opacity value without the ".", which—if you change the underlying values of the scale—becomes misleading. But if the solution to that was to change to a different scale completely, eg 400, 500, etc the user misses out on having insight into what the underlying value is (when they haven't been changed). Hmm.

@stowball
Copy link
Owner Author

stowball commented Aug 5, 2020

It's a tough one, that's for sure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants