New Feature: Update Default Font size.js about numl

[tenphi]

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

[shubham-kaushal]

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]

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.

[shubham-kaushal]

Few Ref.:
https://material.io/develop/web/docs/typography
https://material.io/design/typography/the-type-system.html#type-scale
https://orbit.kiwi/foundation/typography/
https://polaris.shopify.com/design/typography#section-type-scale
https://polaris.shopify.com/components/titles-and-text/display-text#navigation

cc: @tenphi

[tenphi]

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]

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]

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]

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.