Not mobile-first about rfs

[MartijnCuppens]

Why size it in px at all? Why not percent, rem, or vw? The whole layout should be built on one principle or the other: fluid, or not.

I think the main idea is to prevent the text from stretching over wider screens making the text less readable.

I do understand that. If I were using a version of rfs that was mobile-first, I would probably specify my minimum font sizes using the Modular Scale library and then let rfs scale it up - rather than specifying a lot of rem sizes with decimals. That way you keep the ease of use factor and the size relations without having to use a bunch of small decimal numbers.
You can use px if you like, rem-sizes with a lot of decimals are not needed.

If you really want to stick with the mobile-first approach, I don't think RFS-technique will be suitable for you. It's just not designed like that. However, feel free the fork RFS or make something from scratch that's more like what you want.

Anyway, thanks for taking your time to figure out how RFS works and for the given feedback. @garrettw.

[MartijnCuppens]

Hi @garrettw,

The main reason it wasn't designed mobile first is that browsers without vw-unit support will correctly render there font-size.

If we use the mobile-first approach, we get this:
SCSS:

.title {
  @include rfs(62);
}

CSS:

.title {
  font-size: calc(23.6px + 3.2vw);
}

@media (min-width: 1200px) {
  .title {
    font-size: 62px;
  }
}

For older browsers with a screen-width smaller as 1200px the font-size will not be set.

However it might be interesting to add an option like $rfs-mobile-first (default value: false) which switches to mobile first rendering?

[MartijnCuppens]

@garrettw, I just added an option for mobile-first rendering, you can enable it by setting $rfs-mobile-first true.

[garrettw]

The article I linked above does it in a slightly different way. Thoughts?

.title {
  font-size: 12px; /* base, mobile-first size */
}

@media (min-width: 400px) {
  .title {
    /* scaling size for viewports between 400px-800px */
    font-size: calc( 12px + (24 - 12) * ( (100vw - 400px) / ( 800 - 400) ));
  }
}

@media (min-width: 800px) {
  .title {
    font-size: 24px; /* largest size for widest viewports */
  }
}

[MartijnCuppens]

The purpose of RFS is to make font-resizing as easy as possible, you only need one font-size, resizing is done automatically.

For the method you mention, you will need a minimum and maximum font-size for each element where you want to set the font-size for. Aside from that, you will need to make sure you never cross-size texts (for example a text with a minimum of 14px and a maximum of 18px and an other text with a minimum of 15px and maximum of 17px).

[garrettw]

True, you would have to know the min and max for each element. But what do you mean about cross-sizing texts? I don't understand the issue.

I understand that your mixin is focused on ease-of-use with only one parameter. In that case, it might make more sense to me to specify only the smallest font size in the parameter, and then scale up infinitely, based on some $rfs-factor - because there is a practical limit to how small screens can get, but not much limit on how large they can get.
Do you think that could be at least as user-friendly as your way (if not more so)?

[MartijnCuppens]

If you have a project where a lot of font-sizes are used, you need to remember which minimum/maximum pairs you have combined. If you have a text element with a font size of 14px on mobile and 18px on desktop and you have another element which has a font-size of 15px on mobile, you need to remember to use at least a font-size of 19px on desktop so that the importance of the text-elements remain in relation with each other. If that's not totally clear, don't mind, my point was that RFS is a bit easier to use because it only has one parameter.

I'm starting to understand where you want to go with the mobile-first approach. However, I do think there really is a need for a maximum font-size and not the minimum font-size.

For example, let's take Github. It has a container-width of 980px, if the sizes would scale up infinitely, I would definitely have a problem with bigger titles on my 2560px wide screen.

If you're used to work as a mobile-first developer RFS would indeed feel a bit strange, because it actually works the other way around. However, you need to see the value that is passed to the mixin more as a number that indicates the font-size, rather than an exact font-size. When I was working with RFS for mobile devices, I never know exact how big the font-size of an element was, but I did know what value it is. (this was by far the most vague explanation I gave on Github, but I hope you somehow know what I mean)

[garrettw]

If you have a text element with a font size of 14px on mobile and 18px on desktop and you have another element which has a font-size of 15px on mobile, you need to remember to use at least a font-size of 19px on desktop so that the importance of the text-elements remain in relation with each other.

Ah ok, that is clear now. The relation between the sizes is what you were talking about. That makes sense.

For example, let's take Github. It has a container-width of 980px, if the sizes would scale up infinitely, I would definitely have a problem with bigger titles on my 2560px wide screen.

That certainly would be a problem, but the cause is the fixed px-sized container width. Why size it in px at all? Why not percent, rem, or vw? The whole layout should be built on one principle or the other: fluid, or not.

However, you need to see the value that is passed to the mixin more as a number that indicates the font-size, rather than an exact font-size.

I do understand that. If I were using a version of rfs that was mobile-first, I would probably specify my minimum font sizes using the Modular Scale library and then let rfs scale it up - rather than specifying a lot of rem sizes with decimals. That way you keep the ease of use factor and the size relations without having to use a bunch of small decimal numbers.