Change grid and container sizes from em/rem to px

[glebm]

Changes grid and container sizes to px, as the viewport pixel size does not depend on the font size.

The actual em values were inconsistent with the docs, while the docs were not the same as the comments:

• sm breakpoint was 34em (544px) not 480px.
• lg container max-width was 60rem (960px), less gutter than md.
  Changed to 940px, same as Bootstrap 3.
• xl container max-width was 72.25rem which is 1140px not 1156px.
  Changed to 1140px matching the comment but not the docs.

Addresses #17070 and #17388.

[glebm]

Rebased

[cyrildc]

Will xs breakpoint be 0-479px and sm 480-767px?
480px seems too small for columns
e.g http://v4-alpha.getbootstrap.com/ you've set col-sm-4 which will be too narrow at 480px

While 34em (544px) which is currently used on the v4 demo seems more pratical.

[glebm]

@cyrildc Perhaps, yes. I am leaving actual values up to @mdo, the values here are taken from the respective documentation (which is not consistent with the em values).

[cvrebert]

Note: #17569 will be moot if this gets merged.

[mdo]

Let's bring it back to around 560px if we can. I forgot exactly why we did that, save for perhaps the widely varied mobile device sizes.

[glebm]

@mdo Done.

[glebm]

Rebased and updated bootstrap-grid.scss.

[mdo]

Thanks @glebm! <3

[hebbet]

@thibautsapient i talk about that with a friend a few days ago and was going to comment here to. maybe i will take the time an make a new PR for it.

one comment on:

sm breakpoint was 34em (544px) not 480px.

34em was wrong 30em is 480px.

[patrickhlauke]

FWIW i'd be in favor of maintaining breakpoints in em. if calculated properly (to match what the px value was supposed to be, based on general default of 16px/1em), it would make no difference to most folks, but would automatically cater (at least from a general layout switching point of view) for differently set font sizes.

[hebbet]

maybe an option like $enable-em-breakpoints: false !default; code solve it.

[patrickhlauke]

Coming in late, but I'm actually not quite sure what problem switching to px from em tried to solve. And don't quite see the point of making it optional at this stage (unless I'm missing out on why the change was made in the first place)

[hebbet]

Coming in late, but I'm actually not quite sure what problem switching to px from em tried to solve

maybe @mdo or @glebm could explain it a little bit

[niutech]

In my opinion, the em case is marginal (how many % use e.g. "zoom text only" in Firefox?) but it adds much inconvenience in terms of converting viewport values expressed in px into em. Is a device width 600px or 37.5em? The first one is much more convenient.

[ghost]

@niutech probably not many, indeed, but a lot of vision impaired people set their minimum font-size to something higher than 16px, and ignoring them a) is not very nice b) could potentially make your website fail the WCAG guidelines tests, which is a big issue if you are working on government websites (most countries require a AA level). Disabilities are marginal too, but everybody has a right to access your information.

And to answer your question, a device is 37.5em when the window size is set to 600px in most cases, but could become 18.75em if the user has doubled his base font size. So the second one is definitely more convenient for that user, while not adding any inconvenient to the lambda user.

[bulk8752]

I solved this problem in a custom rewrite of Bootstrap 3.2. The main problem revolves around the initial font-size declaration. I broke with tradition and set the initial value to 100%. This was the result of a though experiment my team and try and find a way to give a proportional appearance of containers and components relative to the pixel density and device size. I'm sure many of us have done this and of course we couldn't get it to work perfectly. However, one of the advantages of declaring your initial font-size to 100% is that the rem value will change depending on what the browser feeds it. Most browser will feed in 16px of course, but high definition devices will have their browsers feed 32px and so forth.

Instead of using em for breakpoints, we used rem. I think some of the arguments in this thread are valid in that our media queries use set viewport widths. Those values will not change in any particular browser, but among browsers they do change. For simplicity, a max-width of 20rem is 320px. This will not change for this browser, but on an iPhone 20rem will convert to 640px. Using this method, we don't have to create custom media queries for hi-rez devices. Is the proportion always exact? No, but it takes a ton of work off the table in the end.

I am disappointed in the decision to convert back to px. If I decide to go with Bootstrap 4 I will have to rewrite all of the breakpoints, layouts, and components to rem again. This is an arduous task. I may even decide to extend my current version of Bootstrap 3 to include some the new features you are building now instead. You state that you were not getting the value conversions that you were expecting. I fail to see how this is a bad thing. These values should flex. This is the advantage of using a relative metric. The only place I don't use a relative metric is in borders and special styling elements like shadows. Pixels should be absent wherever they can.

[niutech]

Pixels should be absent wherever they can.

I don't agree. Being the web developer for a long time, I always used
px for container sizes, margins and paddings, because it is natural,
intuitive and it is how designers reference them. Em and rem are
font-relative lengths (see the specification), so they are meant for
font sizes. It is pointless to use them everywhere. See this post:
https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/

That said, rewriting all the breakpoints from default px to em is a
matter of three lines of SCSS/LESS.

[endrep0]

Will there be breakpoints for 4K etc?
Like this stuff: http://benwhitehead.github.io/bootstrap-big-grid/

[ultron1980]

34em was wrong 30em is 480px.

Only if the base font is 16px. If the base font is 14px, 30em is 420px. As you change the base font, your em media query break point in relation to the window width in px will change. Thus, you can no longer speak in terms of large device, medium device or small device breakpoints, but rather decide how the layout will be arranged at a given base font size,say 16px for a specific window width, and then let ems/rems work on the elasticity bit at other base font sizes - which they will. The break point will kick in sooner or later, depending on whether the base font is increased or decreased.

We'll also have to remember that the max-width, min width, font sizes defined thus, in ems, will be based on the fact that we have set the html base font size to 100%, so that it matches the base font size for our calculations - else, the units defined for widths, heights and font sizes will increase/decrease based on the font % set in the code but the media queries would still kick in based on the browser base font, regardless of what's defined in the code (which, at least as far as I've observed, only changes when the browser base font size is changed). For perfect elasticity, all min-widths/max-widths and min heights/max-heights will have to be defined in ems or rems - mixing units would be pointless (for instance, introducing pixels) in this case and may even result in incorrect results. I think anyone wanting to switch to ems/rems would have to embrace this philosophy completely for them to be accurate and effective. I also think it is difficult to achieve granular accuracy using ems. Image sizes are also calculated in pixels, as far as I have observed, so this could be tricky.

I'm also of the opinion that with the current settings, anything the user does with his/her browser settings gives accurate results - if he/she zooms in/out, the page zooms in/out and everything gets larger/smaller, exactly as the zooming option is supposed to perform. If the user changes his/her base font settings , they are doing just that - increasing the base font - getting a different layout isn't implied.

[patrickhlauke]

If the user changes his/her base font settings , they are doing just that - increasing the base font - getting a different layout isn't implied.

it's not about it being implied, it's about "if they change the base font settings, the layout will adapt to better fit this content"

[glebm]

@patrickhlauke But this depends on the content. For a website where the primary content is images, changing the layout with the base font size might not be ideal. But seems like this should be at least an option.

[saddam-azad]

This is by far the most painful issue with B4. Using rem for breakpoints should be the default but there should be an option in _variables.scss to revert back to px.

Regarding the breakpoints and container-max-width, the 34rem and 72.25rem produce widths (with base font-size of 16px) that are not divisible by 12 (hence producing uneven columns in different browsers). I think it should be simplified as follows:

$grid-breakpoints: (
  xs: 0,
  sm: 34em,   // 544px
  md: 48em,   // 768px
  lg: 62em,   // 992px
  xl: 75em    // 1200px
) !default;

$container-max-widths: (
  sm: 30rem,    // 480px
  md: 45rem,    // 720px
  lg: 60rem,    // 960px
  xl: 71.25rem  // 1140px
) !default;

[saddam-azad]

940 is not divisible by 12. Please change to 960.

[jrochkind]

As I figure out my site being rewritten in Bootstrap 4, it looks to me like browser zoom is working worse in my site rewritten for Bootstrap 4 than it did in Bootstrap 3. Testing using Chrome just the standard zoom-in and zoom-out features.

When zooming in the Bootstrap 4 site, at some point the things in the grid become large enough that they don't fit in the flex container, so flex elements wrap to the next line. That is, at some zoom-in, you no longer actually can fit 12 columns on a page, some of the columns start wrapping.

In the Bootstrap 3 site, this same point that they'd get too big to wrap is the point the media breakpoint would kick in, so it would work out that 12 columns always fit on a page.

I believe this is a consequence of Bootstrap 4 using pixels for it's media queries, but rem for most everything else. Whereas Bootstrap 3 used px for each. Which led me to this issue.

The point of using rem for font size is supposed to make user-requested larger font-sizes work better, but in my site they seem to be working worse.

It's also possible I"m misunderstanding what's going on, this stuff gets very confusing.

But the hunt to figure it out led me here, and I don't really understand the justification for switching back to px for media breakpoints, when earlier Bootstrap 4 pre-releases were using relative sizes. There isn't actually a lot of explanation on this ticket. Does anyone know if there's more explanation/justification to be had somewhere? I don't really understand what's going on with this choice or what it was intended to do or accomplish.

[glebm]

The point of using rem for font size is supposed to make user-requested larger font-sizes work better, but in my site they seem to be working worse.

Yes. This PR only means that changes to the root font size don't change the media breakpoints. As you mention zooming, it's unlikely that this change is what's affecting
your site.

It's also possible I"m misunderstanding what's going on, this stuff gets very confusing.

For actual zoom (as opposed to only the root font size change), px vs rem doesn't matter.

For root font size change, the font sizes change but other elements, such as images, remain intact. If the user only increases the root font size but not overall zoom level, that usually means they want the layout to remain intact.