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

Generic Text Style Mixins #100

Open
alexgetty opened this issue Jan 26, 2021 · 2 comments
Open

Generic Text Style Mixins #100

alexgetty opened this issue Jan 26, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@alexgetty
Copy link
Contributor

I have a set of mixins I use to apply the same basic text style variants to a bunch of different text-based components. It allows a consistent application of stuff like coloring, italic, bold, uppercase, alignment, etc. I'd like to include these in this project and update text components to include these options. They can be mixed and matched together to create a lot of variations.

Here's an example of what some of them look like:
Screen Shot 2021-01-26 at 3 55 43 PM
Screen Shot 2021-01-26 at 3 57 25 PM

@brandongregoryscott
Copy link
Contributor

Fine with me. Two thoughts

The naming structure in the typeSizes mixin is pretty limiting. What's larger than largest, or smaller than smallest? An approach we've taken on projects recently has been 'x' modifiers to allow a wider range: small, xsmall, xxsmall, etc.

The -inverse modifier could be problematic depending on the color palette for the app - what do you do for dark modes?

@brandongregoryscott brandongregoryscott added the enhancement New feature or request label Feb 3, 2021
@alexgetty
Copy link
Contributor Author

Thanks for the feedback!

I agree the naming structure can be a little limiting. In fact, that is by design. Type hierarchies with a set number of steps on the scale force designers to stick to a predetermined number of size increments, creating more consistency and reigning in our (designers) tendencies. Same reason you don't want 30,000 shades of grey in a project's color scheme. I used it as a way to force good practice for myself, but for dev teams that don't have a close collaboration with whoever is designing something, this would be problematic. That's a long way of saying that I'm totally fine changing the naming convention.

I see what you mean about the -inverse issue. When I used this template for dark sites, I just flipped the color value in the inverse tag, easy peasy. But for a repository intended to be consumed via npm modules, this doesn't work. We could either remove that one for now, or if we already have a standardized way of handling light/dark modes in theming, we could leverage that to create a smarter tag that conditionally shows light or dark based on what theme is selected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants