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

Typography: can we agree on a solution for responsive type setting/modular scale #11

Open
renatodeleao opened this issue Feb 22, 2019 · 0 comments

Comments

@renatodeleao
Copy link
Collaborator

renatodeleao commented Feb 22, 2019

I'm doing css for almost 6 years now. I still don't have a reply for "how to properly set consistent responsive typography on a web page", despite the 123812831 articles i've read.

If some want's to tackle this here's what the minimum expected:

  • A map/variables to define font-sizes + line-height pairs, and scale multiplier,
  • A mixin/function to include responsive font-sizes.
  • A mixin/function to include font-sizes from the scale, without the responsiveness for custom places, like menus bars and other specific components.
  • Naming: the naming methafors can go wild really u-fs-sm is really hard to grasp in what part of the scale because it could exist infinite variations xsm xxsm tailwind style, then sometimes line-height needs to be reseted for a menu or something. Greek styles alpha beta gamma, i'm sorry i can't remember all the names neither their order (maybe i'm the only one). We could use the same nx of spacing where n is the multiplier vs the baseline. Maybe we can use the same for base font-size. if base font-size is 16px, u-fs-2x = 32px, but for smaller variations we would need to wrap our heads around the math like using ems or rems but can be better.
  • Then you have exceptions: display headings (those jumbo big typesettings for specific situations)
  • I've seen people advocating for literal naming u-type-16 => 16px but in rem with companion line-height and letter spacing. My scalable sense was against it when i first saw it, but i do start to think that the advantages (instant reckon) outcome the disadvantages (dom tied to css, changin css requires change in html, but damn, how often do you change a typescale? that should be like the first thing in the process, and we can always add more types as in, we won't reach more than 20 styles i would say ref)

The old way used to be something like this, plus an extra-field to the letter spacing. If you think this is enough we can easily add it.

Some tools and references to get started

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant