Change grid and container sizes from em/rem to px #17403

Merged
merged 1 commit into from Sep 28, 2015

Projects

None yet
@glebm
Member
glebm commented Aug 31, 2015

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 glebm added css v4 labels Aug 31, 2015
@glebm
Member
glebm commented Sep 8, 2015

Rebased

@cyrildc
cyrildc commented Sep 10, 2015

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
Member
glebm commented Sep 10, 2015

@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
Member

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

@mdo
Member
mdo commented Sep 16, 2015

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
Member
glebm commented Sep 16, 2015

@mdo Done.

@glebm glebm Change grid and container sizes to px
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.
eabed0e
@glebm
Member
glebm commented Sep 27, 2015

Rebased and updated bootstrap-grid.scss.

@mdo mdo added this to the v4.0.0-alpha.2 milestone Sep 28, 2015
@mdo mdo merged commit 0240136 into v4-dev Sep 28, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@mdo
Member
mdo commented Sep 28, 2015

Thanks @glebm! <3

@mdo mdo deleted the use-px-for-window-sizes branch Sep 28, 2015
@cvrebert cvrebert changed the title from Change grid and container sizes to px to Change grid and container sizes from em/rem to px Nov 23, 2015
@ultron1980

I have always wondered why anyone would want to set the media queries and max grid widths in ems if they were going to work with set view-port widths (worked out in pixels) or if the base font was going to be set in pixels - defeats the whole purpose of using ems which, if I'm not mistake, was introduced so that the default browser font settings could be changed which would/should then change the font sizes, max grid width, and media query breakpoints proportionally - provided the html font size is set in % and everything else is set in ems/rems. If the base font size is set in pixels, it's pointless using ems since a) the break points would still be based on the browsers font settings making them inconsistent for the intended zoom level b) All font sizes and max-widths would be the same as their pixel equivalents and unchangeable, defeating the whole purpose , especially since it is easier and better to work with pixels if there is no elasticity benefit.

@thibautsapient

Maybe some people should read http://zellwk.com/blog/media-query-units/
imho, Going back to px is a big mistake.

Also, breakpoints set in pixels will miserably fail in Firefox when the "zoom text only" option is enabled because you'll end up with tiny columns trying to cope with huge fonts, whereas ems breakpoints are perfectly fine with that (you kinda end up with a big mobile version)

If you care about accessibility (or if this is a requirement), then bootstrap v4 is not an option anymore.

@hebbet
Contributor
hebbet commented Mar 29, 2016

@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
Member

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
Contributor
hebbet commented Mar 29, 2016

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

@patrickhlauke
Member

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
Contributor
hebbet commented Mar 29, 2016

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
niutech commented Mar 30, 2016

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.

@thibautsapient

@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
bulk8752 commented Apr 8, 2016

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
niutech commented Apr 8, 2016

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.

@endrepalinkas

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
Member

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
Member
glebm commented Apr 9, 2016

@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.

@cvrebert cvrebert added a commit that referenced this pull request Apr 19, 2016
@cvrebert cvrebert Add Wall of Browser Bugs entries for https://webkit.org/b/156684 & ht…
…tps://webkit.org/b/156687

These bugs are factors in our decisions regarding which unit to use in our media queries.
Refs #17403
[skip sauce]
0e56cbb
@azadcreative
azadcreative commented May 6, 2016 edited

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;
@azadcreative azadcreative commented on the diff May 7, 2016
scss/bootstrap-grid.scss
//
// Define the maximum width of `.container` for different screen sizes.
$container-max-widths: (
- sm: 34rem, // 480
- md: 45rem, // 720
- lg: 60rem, // 960
- xl: 72.25rem // 1140
+ sm: 576px,
+ md: 720px,
+ lg: 940px,
@azadcreative
azadcreative May 7, 2016

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

@azadcreative azadcreative commented on the diff May 7, 2016
scss/bootstrap-grid.scss
//
// Define the maximum width of `.container` for different screen sizes.
$container-max-widths: (
- sm: 34rem, // 480
- md: 45rem, // 720
- lg: 60rem, // 960
- xl: 72.25rem // 1140
+ sm: 576px,
@azadcreative
azadcreative May 7, 2016

How can container width ever be wider than the breakpoint?

@cvrebert cvrebert added a commit that referenced this pull request May 28, 2016
@cvrebert cvrebert Port #19765 to v3
Add Wall of Browser Bugs entries for https://webkit.org/b/156684 & https://webkit.org/b/156687

These bugs are factors in our decisions regarding which unit to use in our media queries.
Refs #17403
[skip sauce]
21d9175
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment