Bootstrap: Why has Bootstrap 4 changed to using rem?

[cyphix333]

I know a lot of people like to use rem these days, but I'd like to know what is the reason behind changing to using it over px?

Not only is pixel units far easier to work with, research shows that they should be used over rem units.

https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/
http://stackoverflow.com/questions/11799236/should-i-use-px-or-rem-value-units-in-my-css

Seems a little odd to go backwards in V4 when V3 was using pixels.

[patrickhlauke]

research...or just opinion pieces? the one aspect that rem still handles that px doesn't are user settings and user agents which don't use 16px font size baseline. https://nicolas-hoizey.com/2016/03/people-don-t-change-the-default-16px-font-size-in-their-browser.html

[cyphix333]

Look I don't pretend to be an expert on these things, but I wouldn't say those links I posted are opinion pieces; the first one most certainly based the article on a _lot_ of research that he did and made some strong points and it most certainly isn't the only article stating to use px over rem.

Either way you look at it IMO there isn't a massive difference between the two in accessibility for the user but px is certainly far easier to work with for the developer.

[praveenpuglia]

For me personally, rems provide a lot of good while working.

1. It's easier for me to think of margin and padding values as rem values because it allows me for simpler understanding of them and keep them consistent. Example - 1 unit of margin all around or twice the margin around.
2. With rems, it's easier to get text behave responsive because it's dependent only on one declaration at the root element. While customizing bootstrap for my own project, i had to scale text in every component down from 16px base to 14px base and it was a hell lot easier to do with rem.
3. In general practice, I have realized that it allows me to have a more robust grid and sizing of elements with less number of unique values.

[stemd]

If DPI would be constant across different devices across time, px would be OK to use. But when you check new 4K screens, most of them are packing twice more pixels in the same space, and basing design on pixels means everything will be too damn small.
Of course, there are exceptions, like ~40 inch monitors having 4K res which keep DPI, and increase both size and resolution, but they are minority.
Use of any kind of relative units is in long term better solution than use of unit which size is highly dependent on technology. Yes, web sites need to change from time to time, myself and my colleagues need to be paid, it's not a good idea to make some web site too good so owner won't need to invest some money for web devs services once in a while, but counting on pixels simply feels wrong.

I understand why someone feels px is the right unit (for some limited cases it IS the RIGHT UNIT), but once again, number of such cases is LIMITED. I'll give an example, to put this to rest:

Lets say you are making design for an in-house app in some rather big company which for some reason is using quite standardized equipment, like some big bank, which before used Oracle Forms or similar "toolkit" with fixed grid size, and they want exactly the same layout and fonts and ...., which is not a problem for them as they have specification for equipment they buy in large quantities, and there is no odd equipment (monitors) with DPI higher or lower than usual, they ALL have the same monitors of same size which are working on same resolution, and if a new app for this would not be made in Java but in JavaScript or Python and you would have an opportunity to make UI with CSS/JS framework of your choosing, using relative units in your design would be quite probably poor choice, as you would get expected result sooner and easier to be according to specification if you would be using px.

But as I wrote at the beginning, number of such use cases where usage of px is not just better, but preffered way is severely LIMITED.

[cyphix333]

Thanks for your post @stemd but I believe that first article covered the DPI aspect.

[stemd]

TLDR disclaimer (forgot it last time :))
You are right @cyphix333 , first article mentioned:

reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm’s length

Only thing is that standards or proposed standards in IT are not written in stone, sometimes software vendors are promoting new standards, and sometimes they are just implementing them.
If unit used in CSS is px, which stands for reference pixel, that IS good enough, I agree, if all vendors are implementing that.
As I hear, not every OS and app is scaling to 4K the same. Idea is - apps need to scale according to technology changes, and how they will do it (which units will scale) is irrelevant.

It is surely misleading if browsers scale pixels and OS level GUI toolkits like Qt, GTK, WxWindows doesn't, but as newer versions of both Qt and GTK both implement CSS styling of its components (Qt5 and GTK3 do, it's quite nice, actually), I suppose if all browsers will support "reference pixel", OS toolkits will probably do likewise, eventually. Time will tell.

_Disclaimer:_ OS toolkit discussion is a bit out of scope here as Bootstrap is CSS framework and not GUI toolkit, I'm aware, but from our (users) viewpoint, we just want that software we use scale well, and when that does not happen, we are forced to dig through the registry or settings and tweak. That should not happen, and only way is if some relative unit is clearly both defined as relative to screen size and scaling with DPI change. Hopefully if we once switch from 4K to 8K or something, then everything will scale without end users ever noticing.

[Jakobud]

...when you check new 4K screens, most of them are packing twice more pixels in the same space, and basing design on pixels means everything will be too damn small.

@stemd

Uhhh..... have you ever heard of device pixel ratios?

[stemd]

@Jakobud Wrong address, ask authors of toolkits why their software is not scaling.

[patrickhlauke]

closing this, as the discussion is getting circular. point is: rem takes the browser/user's base font size (usually 16px, but not always) as a starting point. if a user has set their browser to explicitly use a different default font size, or if it's a device/browser which sets a different font size, this unit will allow for it.

px in browsers is "CSS pixel", not hardware pixel, so 4K/8K are a red herring in most cases, since the browser (provided the OS is sane) will have whatever the browser/device manufacturer/user has deemed to be an appropriate resolution/dpr and the CSS pixel will correspond to whatever the device pixel ratio demands. yes, in most modern browsers zooming by default also enlarges the size of the CSS pixel/modifies the browser's interpretation of the dpr, so scalability is nowadays also achievable quite comfortably with px units. however, the missing part is that px units don't take into account browser/user default font size. as such, rem still win out.

[Jakobud]

A while back I proposed that Bootstrap use a SASS mixin that converts px units to rem's, as a middle-ground solution. That way people have the comfort of using the familiar px values but all the resulting css will be using rem. Zurb did this with Foundation a while back and it was very nice. But I think the main Boostrap guys did not care for this approach for some reason. I was never sure what the problem was.

[dotnetCarpenter]

Just want to add one really really cool thing about REM.

You can create websites that scales the design perfectly to the screen or window size. Not sure what to call it, maybe _scalable_ design since liquid and elastic is already taken.

Say we have the following CSS:

html {
  font-size:62.5%; /* not really needed but make calculations from design to screen 1 to 0.1 */
}
@media screen (min-width:640px) and (max-width:1000px) {
  /* here we say scale everything between 640px screen width to 1000px screen width
     to look the same (e.g. scale to the exact same proportions) */
  font-size: 1vw;
}

_There is a natural lower and upper bound for when design is too small or too big, but this technique makes everything in between look exactly like the designer envision_

Check it out here (between 640px and 100px): https://www.firefund.net

I have used this technique for years (since 2013) and have only en-counted one bug in Chrome and Safari, when you scale below font-size below 9px. So only use this for tablet to desktop design.

Another scale everything demo (which glaringly show the bug in blink/webkit): http://dotnetcarpenter.bitbucket.org/bugz/rem-bug/

[patrickhlauke]

FWIW scaling using just vw/vh results in pages that simply can't be scaled/zoomed on desktop browsers (since zooming changes the browser's "virtual" pixel density, it changes the viewport size - any pure vh/vw based font sizes render exactly at the same size - since the window's proportions etc haven't actually changed, and those measurements are meant to maintain the relationship to the viewport).

[dotnetCarpenter]

One last gotcha. Don't ever set width, height or border to 0.01rem; instead of 1px. Browsers will eventually round it down to 0px (things will disappear). You can use min-height: 1px; and min-width: 1px; in conjunction with 0.01rem; to remedy though.

[dotnetCarpenter]

@patrickhlauke Not if you use it within media queries. Then you can scale as usual. Try it out on https://www.firefund.net

[patrickhlauke]

Yes even when you use it in media queries - for those sizes where the viewport width falls between those min/max values (that zone where your sizing is purely in vw/vh) the text remains unzoomable. once you zoom up/down enough to escape that zone, then yes normal sizing works again.

[dotnetCarpenter]

Yes you're right. Guess a another gotcha is that you should always use media queries with a small range. I only use it for translating desktop design to tablet sizes, and the technique is successful at that. Never had any problems zooming on touch screens, not sure if that is because they _out-range_ the media query so fast or they just don't change the meaning of vw/vh.

Another option is to use a small script. I did that the first 2 years.

[cyphix333]

A while back I proposed that Bootstrap use a SASS mixin that converts px units to rem's, as a middle-ground solution. That way people have the comfort of using the familiar px values but all the resulting css will be using rem. Zurb did this with Foundation a while back and it was very nice. But I think the main Boostrap guys did not care for this approach for some reason. I was never sure what the problem was.

Yeah, seems a bit silly not to provide one.

[patrickhlauke]

Never had any problems zooming on touch screens, not sure if that is because they out-range the media query so fast or they just don't change the meaning of vw/vh

The latter. On mobile/tablet devices, zooming does not change the actual width/height of the layout viewport (which is why you get horizontal/vertical scrolling) nor the "virtual" dpi, while on desktop browsers zooming both are modified.

Related, I experimented around with this topic recently http://codepen.io/patrickhlauke/pen/PbXvmP

[dotnetCarpenter]

Guess you're not really sold on the technique @patrickhlauke?