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

New Feature: Update Default Font size.js #124

Closed
shubham-kaushal opened this issue Jan 3, 2021 · 8 comments
Closed

New Feature: Update Default Font size.js #124

shubham-kaushal opened this issue Jan 3, 2021 · 8 comments

Comments

@shubham-kaushal
Copy link
Member

Update: Simplify the Font scaling. The typographic scale update designed to keep the number of separate styles to a minimum including the responsive based on LARGE SCREEN & SMALL SCREEN #117

image
image

@tenphi
Copy link
Collaborator

tenphi commented Jan 11, 2021

There is no need to create such scaling. Font size depends on logical pixel density which should be similar across the devices.

@tenphi tenphi closed this as completed Jan 11, 2021
@shubham-kaushal
Copy link
Member Author

There is no need to create such scaling. Font size depends on logical pixel density which should be similar across the devices.

I am discussing default size https://numl.design/reference/styles/size Instead of defining s, m, lg, h1, h2, etc. we can define a clear default font size like the proposed method (caption, body, subheading, etc.). And, I disagree with having similar density font sizes across the devices because it's not very much responsive, and neither a good example of accessibility. If our intention is to create a Design System as a Service then we should define our default the way we actually implement it while creating the style guide of any project.

@tenphi
Copy link
Collaborator

tenphi commented Jan 11, 2021

Numl should stay as a universal solution.
caption, body, subheading, etc - all of them are not universal and depend on a project.

having similar density font sizes across the devices because it's not very much responsive, and neither a good example of accessibility

Never heard of it. Let me some time to research.

@tenphi
Copy link
Collaborator

tenphi commented Jan 11, 2021

So only Material Design uses different scales for mobile. Well, in Cube Dev we use it too but it doesn't mean everyone should use them.
It's very simple to customize scales in Numl for every screen width. So I don't see any reason it should be built-in. Default scale works for every device.
Also, you can scale down the size in place: size="h1|h3".

@tenphi
Copy link
Collaborator

tenphi commented Jan 11, 2021

Built-in adaptive scales would introduce the unwanted complication of the Design System the users should care about. There is always a compromise to achieve both simplicity and flexibility.

@shubham-kaushal
Copy link
Member Author

shubham-kaushal commented Jan 11, 2021

I highly recommend Responsive Font. And naming it as caption, body, subheading is actually will simplify the complexity and it's an anatomy of any app typography (writing it as h1, h2 is primitive). Even Tailwind is considering this and I feel tailwind is one of the alternatives to Numl in terms of modern approach https://tailwindcss.com/docs/font-size Maybe you can check the Shopify polaris from the above link, there approach also looks promising by making certain ex.: h3 default for large screen and naming it as subheading and making it responsive according to screen size etc. In this way you are not removing the existing, instead, you are introducing a default method.

Note: Custom theming is a different case. We can only think to make it more and more customized friendly but for the default version, I will always move to new ways to make it more accessible.

Story: Back in the days we used to create m.example.com and example.com (two different apps because responsive was not coming into the picture) but after bootstrap, we don't need to create the two different versions to create for mobile responsive. Like the same turbolinks got replaced by SPA.

@tenphi
Copy link
Collaborator

tenphi commented Jan 11, 2021

We can discuss different naming. But adaptive font scales are almost impossible in the current approach of Numl.
Even with default responsive breakpoints, it would not be easy to implement adaptive scales.
And so far, it's just not so important to implement a new approach.

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

No branches or pull requests

2 participants