Bootstrap: v4 - Consider using px-to-rem conversions instead of hard-coded rem's

Created on 19 Aug 2015  路  30Comments  路  Source: twbs/bootstrap

For readability reasons I would consider using a px-to-rem mixin (https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=px+to+rem+sass+mixin) instead of hard coding rem's everywhere. The reason for this is simply because people can more easily recognize what pixel sizes are compared to rems and ems.

For example, everyone knows that a iPad width is 768px. 99% of people aren't going to know what that is in em/rem. But when I look in the V4 source, and I see the the grid sizes for tablet at 48em I'm like "uhhh... okay so how wide is that really? Lets see here, assuming 16px base font size, 16*48=768. Oh that means 768px okay".

It's pretty easy in SASS to do a mixin to convert px-to-rem:

h2 {
  font-size: rem(24);   // 24px value that will be converted to 1.5rem
}

It's very readable. Any developer can look and see that the value is 24px but that SASS is going to convert the final value to rem. Again, it's easy for developers to visualize what 24px is. It's not easy for developers to visualize what 1.5rem (24/16) looks like...

Also, here is proof from the v4 source itself that this should be considered:

https://github.com/twbs/bootstrap/blob/v4-dev/scss/_variables.scss#L106
https://github.com/twbs/bootstrap/blob/v4-dev/scss/_variables.scss#L118

You are feeling the need to add comments to help people understand how big those rems are. Would be a lot more simple to just do:

$container-max-widths: (
  sm: rem(480),
  md: rem(720),
  lg: rem(960),
  xl: rem(1140)
) !default;

It's more readable and results in the same rem values in the end.

So in short, keep everything in rem's in the end product, yes, but use pixels to get there because it's easier to visualize and more familiar to developers. Use SASS mixins to your advantage here.

I would be more than willing to help in this transition if the idea is accepted.

css v4

Most helpful comment

I understand that. But I hope you guys keep in mind there is an extra layer of complexity whenever you look at a rem value and wonder "But how big is that really?" since you have to multiply the rem value by the base font size in your head. People work in pixels all the time. Consider Photoshop, Sketch, etc... Have you ever worked with a designer and told him "Make the padding on that button 1.875rem". He would say "huh?"

It's no question that rems are the best thing to deliver in the end product. But people can simply visualize pixels better and SASS is a mechanism that makes it drop-dead-simple to do the conversion for you. If you are going to use a pre-processor, let's take advantage of it's strengths!

Anyways, I think I've said as much as I can say... It's up to you guys to see the light ;-)

All 30 comments

I would be surprised if this happened after the amount of work to change every px value to rem instead of using px's to start. Not impossible, but just my opinion that it's unlikely

CC: @mdo

I would be surprised if this happened after the amount of work to change every px value to rem instead of using px's to start. Not impossible, but just my opinion that it's unlikely

It would be a piece of cake to script though. It's just simple math.

One other note, that Zurb Foundation has been doing this for a while:

https://github.com/zurb/foundation/blob/master/scss/foundation/_settings.scss

Look for their rem-calc() and em-calc() mixins on the SCSS source.

:+1:

rem(24) is not any better than 1.5rem as 24 doesn't have any unit; I'd go as far as saying that it adds an extra unnecessary abstraction layer.

If you want to do this, you should do it properly: rem(24px).

Not sure if this is the best place to ask as opposed to opening up it's own issue as it's more of a question. But why are you using rem's for anything more than typography? What impact does it have with the grid system & everything else being done in rem as opposed to px?

@DanGamble89 it's because you can do stuff like change the base font size on mobile devices and watch all values scale accordingly. For example, maybe on desktop a margin-bottom: 20px on your <p> tags is good. But at mobile, 20px might be too big. You can either hard code a mobile value or just use a rem value that will scale with the base font size.

@HugoGiraudel Definitely worth considering.

Either we go with rems and ems, or we revert back to pixels. I'm not much of a fan of any middle ground solutions that involve every since value having it's own operation.

@mdo Are you concerned about SASS compile times going up or something?

@Jakobud I hardly think so. It won't make a noticeable difference anyway. I believe @mdo do not want to introduce an extra layer of complexity, especially if unnecessary.

I understand that. But I hope you guys keep in mind there is an extra layer of complexity whenever you look at a rem value and wonder "But how big is that really?" since you have to multiply the rem value by the base font size in your head. People work in pixels all the time. Consider Photoshop, Sketch, etc... Have you ever worked with a designer and told him "Make the padding on that button 1.875rem". He would say "huh?"

It's no question that rems are the best thing to deliver in the end product. But people can simply visualize pixels better and SASS is a mechanism that makes it drop-dead-simple to do the conversion for you. If you are going to use a pre-processor, let's take advantage of it's strengths!

Anyways, I think I've said as much as I can say... It's up to you guys to see the light ;-)

I am against it, even if I totally agree with "better readability". A long time ago @mdo said "most designers think in pixels" for me its still true but I am not sure if this is the case for most now. The future is now so why not learn to think in rems right now rather then rely on some mixins? Then we can write future proof CSS without a preprocessor as well if we need/want to.

"most designers think in pixels" for me its still true but I am not sure if this is the case for most now.

What unit of measurement do you think they use?

@Jakobud by default I'd actually argue pica. It's the default for print designers and the default in tools like Adobe Indesign.

Sorry, but print designers? Thats a whole other industry.

I not thought about another industry ;) nor the Photoshop ... guys.

No sorry by "designers" I meant this type of web guys who mainly/entirely write CSS. Lets not open up this debate about if "designers" code or if they can be designers if they never even touch PS now please.

I was thinking maybe lots of ppl like that actually think in rems/ems by now, I saw a lot of rems lately, and I believe most of them were not generated like in foundation. Aren't there a lot of smaller CSS Frameworks that use for rems for quiet a while now?

I personally think a lot of places the "web" guys aren't just the web guys. That comes from jobs where I've had to do the entire marketing collateral from print through digital media and web. @nextgenthemes I do think there are a decent number of frameworks that use rem/em. I would argue there has been a push to move to em / rem for a few years now just been a slow transition.

I'm +1 for using px values, they can be quickly visualised and understood, whereas rem values require a little more cognitive overhead, and in general slows web dev down.

30px is a lot easier to quickly understand than 1.875rem

Better to set root/html value to 10px, which gives more rounded numbers 30px / 10px = 3rem

Better to set root/html value to 10px, which gives more rounded numbers 30px / 10px = 3rem

This is an anti-pattern. That would be very nice not to see Bootstrap adopt it.

@HugoGiraudel if you would elaborate why exactly it would be bad then that would be actually helpful here.

The only reason to set the base font-size to 10px is for making maths 'easier' or you actually use a base font-size of 10px.

So the only real good reason is if you want the base font-size to be 10px. An old but pretty good write up still on it: http://csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided/

@HugoGiraudel if you would elaborate why exactly it would be bad then that would be actually helpful here.

Sorry, didn't mean to troll or anything. @DanGamble89 started answering your implicit question quite nicely actually. Basically this is a hack. You don't set the font-size to 10px because you want it to be that size. You set it to 10px because you want to ease the math. While that might makes sense on paper, it actually introduces inheritance problems where you have to set the font-size of all the elements back to a decent font size (because 10px is not a decent font size). Basically this hack is a clumsy solution to a problem which shouldn't exist: thinking in pixels. A typographic scale (which is what rem is really good for) should be thought in a matter of ratios rather than absolute values.

Here are a few extra reads on the matter:

In agreement on 16px (the common browser default btw) over 10px. We don't even make use of the 10px thing here in v3.

It would be very useful, I'm struggling with $border-width which should be 1px converted to rem and not hardcoded 0.0625rem. Now reducing the root font-size makes all borders disappear!

@heruan this is a duplicate issue #17210 and is being addressed

@mdo In agreement on 16px (the common browser default btw) over 10px. We don't even make use of the 10px thing here in v3.

In Bootstrap v3 root font-size is set to 10px in scaffolding.less file:

html {
  font-size: 10px;
}

Which is anyway anti-pattern as @HugoGiraudel mentioned

@neilhem I know we have that there, I was mentioning that we simply don't do anything special because of or with that 10px.

Punting on the conversion tool, though we are likely merging #17403 for pixel media queries and what not.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

markoheijnen picture markoheijnen  路  56Comments

juampi picture juampi  路  49Comments

dharmeshpipariya-zz picture dharmeshpipariya-zz  路  38Comments

lpilorz picture lpilorz  路  43Comments

mdo picture mdo  路  66Comments