-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
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. |
Numl should stay as a universal solution.
Never heard of it. Let me some time to research. |
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. |
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. |
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. |
We can discuss different naming. But adaptive font scales are almost impossible in the current approach of Numl. |
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
The text was updated successfully, but these errors were encountered: