Currently there is no font-resizing implemented in Bootstrap. Font resizing is needed to make large texts readable on all devices and to prevent longer words and compounds to fall off screen.
It's currently possible to alter the font size of the html element with media queries (see Responsive typography), but this method can cause the font-size of text to be too small on mobile devices and because the rem-value is overridden, users can't change their font-size in their browser anymore.
RFS can solve this by because this mixin automatically calculates the appropriate font-size based on the width of the device.
RFS is also available in Sass, Less, PostCSS and Stylus.
Example problem with bigger font-sizes:
http://getbootstrap.com/docs/4.1/content/typography/#display-headings
RFS solution:
https://project-rfs.github.io/docs/4.1/content/typography/#display-headings
Bootstrap implementation demo:
https://project-rfs.github.io/
Github page:
https://github.com/twbs/rfs
Pull request
https://github.com/twbs/bootstrap/pull/23816
would love this feature, how do you suggest implementing this though?
what would be my first thought is a class that can be added to the html element, like .responsive-font-size
and would you rather have responsive or fluid font size?
just some questions that pop in to my head
@gijsbotje, for the demo I changed the font-sizes in the _variables.scss-file into unitless numbers like this:
$font-size-h1: 40 !default;
$font-size-h2: 32 !default;
$font-size-h3: 28 !default;
$font-size-h4: 24 !default;
$font-size-h5: 20 !default;
$font-size-h6: 16 !default;
In the .scss-files I changed the font-size -declarations to the RFS-mixin:
h1, .h1 { @include rfs($font-size-h1); }
It's also still possible to use fixed values like 15px or 1.25rem by passing them to the mixin.
So at this moment there is not really a way to enable/disable it per page. However it is possible to alter the mixin by adding a class inside it.
The mixin generates a fluid font size below the rfs-breakpoint, above this breakpoint it would be static (the explanation in detail can be read in the blogpost, https://blog.intracto.com/rfs-automated-scss-responsive-font-sizing)
UPDATE: the implementation has changed and the configuration is kept in rem
Basically, everything is set for this! The only thing missing is to use the $font-size-
Use rem to define the the rythm of the font in mobile (as bootstrap is mobile first) an then adapt the base font size for bigger screens. If you wanna go fancy, allow to set different ratios for each breakpoint (but that's simply not what bootstrap is about). Set a rythm, scale it, and we're fine out here...
Thanks for the input @kimamil. The problem with that approach is that you scale every font-size linear and that means the smallest text will become hard to read. For example, if we take the narrow jumbotron example:
https://v4-alpha.getbootstrap.com/examples/narrow-jumbotron/
If we want to let the title to fit in it's container, we need to set the html font-size to 12px. The result of this is that all the normal text-elements will also have a font-size of 12px and that might be a little to small.
Of course we can just make an exception for that case, and maybe another case and after all, we still need a lot of manual testing to check if there are some edge-cases we need to fix.
Bootstrap is also a framework that is widely used over the world and in some languages a lot of compounds (https://en.wikipedia.org/wiki/Compound_(linguistics)) are used causing longer words and font resizing problems. I speak Dutch myself and I frequently came across these circumstances where I needed to manual test and rescale the font-size while keeping in mind I don't set the font size to small to keep a visual difference between titles and text.
@MartijnCuppens I see, I was a bit overenthusiastic. If it will be a new feature for a next version I guess an overhaul of some current elements/components might be worth it?
As I understand bootstrap it is delivered with a default configuration that works for most, maybe not any language. A customized version can be downloaded, or the ones that need more customization probably work with sass anyway.
So testing and finding a good default value might be easier, if a default language or set of languages is defined? If you need anybody helping testing or so, I might find some time.
Good Luck with implementing.
Is there a PR for this I'm missing? I too find it pretty useful and I'd like to have a look at a PR.
@XhmikosR, I'll make a fork of bootstrap with the RFS implementation this weekend, I'll link to it here. As pointed out by @kimamil, some elements/components might need to be overhauled.
Once we have a solid implementation with documentation I'll make a PR.
I'll keep you posted about further development.
Fork available here: https://github.com/MartijnCuppens/bootstrap/tree/rfs-implementation
@mdo: what is your first opinion on this?
Just FYI folks, when you start using vw units for font sizes (even in a calc()), accessibility goes out the window. In other words, your font will no longer resize when you change the font size in the browser. In a calc() the level of scaling that is lost is dependent on the pixel value that is paired with the vw value. But the problem is still there. And since pretty much every calculated value in Bootstrap is based off of rems, if you use vw anywhere in the base font value, then accessible scaling of the entire interface is going to suffer.
Bootstrap has always maintained keeping accessibility in the forefront and it would be nice to keep it that way. Definitely something to keep in mind if you are considering using vw units for fonts.
But if that is the road that the team is going down, I would also recommend this method (also republished on Smashing Magazine) that I came up with earlier this year, which is simplified and allows you to fluidly scale multiple font sizes across multiple breakpoints instead of one linear scale.
Hi @Jakobud,
Thanks for the feedback. The method you mentioned is indeed a great method, however the complexity of font-resizing increases drastically. Also RFS will take care of relations between font-sizes, with mappings you need to look out for this manually.
The mixin is not applied to the font-size of the html-element, so there won't be a problem with elements that are depending on rems.
responsive-font-size() mixin.rem units. 1rem (16px).1200px, screens with a smaller size will have dynamic rescaling.5.The idea of having responsive typography is great, but IMO the approach discussed in this thread isn't correct. This approach can ruin the vertical rhythm which is a huge typography concern. Font sizes and line height should depend only on breakpoints, never on the screen size.
The lack of properly set up vertical rhythm has always been a problem in Bootstrap. That's why I've been using Gridlover tool and its SCSS implementation Sassy Gridlover and never relied on Bootstrap's font sizes and line heights.
It can't be merged with Bootstrap as it is because Sassy Gridlover doesn't support breakpoints out of the box. But it could be easily extended because it's built in a modular way. So IMO with little effort, you could significantly improve typography.
@MartijnCuppens Implemented here:
@tarkhov: please stop spamming the repo.
@XhmikosR I'm just trying to help people, because I faced the same problems, I can't submit this code to Bootstrap framework, because these features refused or implemented too slow or partially.
You keep spamming the repo, that's a fact. You can help by submitting PRs, testing PRs and so on.
As for delays, we have speed things up a lot, but we still prioritize things.
You can do whatever you want obviously, just stop commenting on each issue/PR here saying that "the X feature is implemented there" especially when something is already merged.
Most helpful comment
Accessibility Warning
Just FYI folks, when you start using
vwunits for font sizes (even in acalc()), accessibility goes out the window. In other words, your font will no longer resize when you change the font size in the browser. In acalc()the level of scaling that is lost is dependent on the pixel value that is paired with thevwvalue. But the problem is still there. And since pretty much every calculated value in Bootstrap is based off ofrems, if you usevwanywhere in the base font value, then accessible scaling of the entire interface is going to suffer.Bootstrap has always maintained keeping accessibility in the forefront and it would be nice to keep it that way. Definitely something to keep in mind if you are considering using
vwunits for fonts.But if that is the road that the team is going down, I would also recommend this method (also republished on Smashing Magazine) that I came up with earlier this year, which is simplified and allows you to fluidly scale multiple font sizes across multiple breakpoints instead of one linear scale.