Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Sep 28, 2015
Merged

Conversation

@glebm
Copy link
Member

@glebm 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
Copy link
Member Author

@glebm glebm commented Sep 8, 2015

Rebased

Loading

@glebm glebm force-pushed the use-px-for-window-sizes branch from 8d64e54 to 2719e6c Sep 8, 2015
@cyrildc
Copy link

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

Loading

@glebm
Copy link
Member Author

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

Loading

@cvrebert
Copy link
Collaborator

@cvrebert cvrebert commented Sep 11, 2015

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

Loading

@mdo
Copy link
Member

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

Loading

@glebm glebm force-pushed the use-px-for-window-sizes branch from 2719e6c to 8158fe8 Sep 16, 2015
@glebm
Copy link
Member Author

@glebm glebm commented Sep 16, 2015

@mdo Done.

Loading

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 force-pushed the use-px-for-window-sizes branch from 8158fe8 to eabed0e Sep 27, 2015
@glebm
Copy link
Member Author

@glebm glebm commented Sep 27, 2015

Rebased and updated bootstrap-grid.scss.

Loading

@mdo mdo added this to the v4.0.0-alpha.2 milestone Sep 28, 2015
mdo added a commit that referenced this issue Sep 28, 2015
Change grid and container sizes to px
@mdo mdo merged commit 0240136 into v4-dev Sep 28, 2015
2 checks passed
Loading
@mdo
Copy link
Member

@mdo mdo commented Sep 28, 2015

Thanks @glebm! <3

Loading

@ultron1980
Copy link

@ultron1980 ultron1980 commented Dec 15, 2015

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.

Loading

@ghost
Copy link

@ghost ghost commented Mar 29, 2016

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.

Loading

@hebbet
Copy link
Contributor

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

Loading

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Mar 29, 2016

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.

Loading

@hebbet
Copy link
Contributor

@hebbet hebbet commented Mar 29, 2016

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

Loading

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Mar 29, 2016

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)

Loading

@hebbet
Copy link
Contributor

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

Loading

@niutech
Copy link

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

Loading

@ghost
Copy link

@ghost ghost commented Mar 30, 2016

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

Loading

@bulk8752
Copy link

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

Loading

@niutech
Copy link

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

Loading

@endrep0
Copy link

@endrep0 endrep0 commented Apr 9, 2016

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

Loading

@ultron1980
Copy link

@ultron1980 ultron1980 commented Apr 9, 2016

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.

Loading

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Apr 9, 2016

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"

Loading

@glebm
Copy link
Member Author

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

Loading

cvrebert added a commit that referenced this issue Apr 19, 2016
…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]
@saddam-azad
Copy link

@saddam-azad saddam-azad commented May 6, 2016

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;

Loading

xl: 72.25rem // 1140
sm: 576px,
md: 720px,
lg: 940px,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

cvrebert added a commit that referenced this issue May 28, 2016
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]
@febLey febLey mentioned this pull request Feb 16, 2017
chiraggmodi pushed a commit to chiraggmodi/bootstrap that referenced this issue Apr 8, 2019
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 twbs#17403
[skip sauce]
@jrochkind
Copy link

@jrochkind jrochkind commented Jun 13, 2019

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.

Loading

@glebm
Copy link
Member Author

@glebm glebm commented Jun 13, 2019

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.

Loading

hbrls added a commit to nice-fungal/bootstrap that referenced this issue Jul 18, 2020
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 twbs#17403
[skip sauce]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet