Bootstrap: What is the actual point of .container as default vs .container-fluid?

[nextgenthemes]

Excuse me if this came up before, I don't know what to search for.

So I actually do not get the point of .container with its fixed widths at all. Why does it exist? Whats the point?

With this many different screen sizes nowadays its even more annoying I think. Why would anyone want to have the layout to suddenly stuck to this fixed breakpoints? Whats the point to have whitespace of 1cm on the sides on one tablet and on the next just 0.2cm for example?

On top on this I have followed BS for a long long time now and saw countless issues to related to .container and always asked myself "why even use it?". Zoom issues, scrollbars appearing I think the media queries still need to be in px and cant be rem based, that has some negative consequences I believe, so many problems that all can be avoided.

I have seen many very famous sites out in the wild (not BS based) and pretty much nobody is doing it this way. I argue that almost all BS users just used .containers because they are the default and are used in all the BS examples and the docs and that just limiting the max-width of a .container-fluid was never part of BS.

It for sure can't be for pixel perfect design because that not possible in CSS. You cant really plan when text breaks lines ... I am really trying hard to figure out what its all about.

To me .container makes not much sense at all, I think there should be a max-width variable for .container-fluid probably just problematically take the latest from the breakpoint withs of .container

To me .container translates to = waste of precious screen space on lower screens but great max-width for xl screens.

With this few lines of CSS we can have pretty much the fluid version of container.

.container-fluid {
  max-width: 1200px;
}

@media screen and (min-width: 600px) {
  .container-fluid {
    padding-right: 3rem;
    padding-left: 3rem;
  }
}

Resize your browser window from very small to very big on this pen to see.

Related:

21901

21530

and many many more.

[nextgenthemes]

@DavisMiculis could you share the reason for your downvote please?

[ghost]

@nextgenthemes i don't think we should remove .container.

The reason is because there are lots of web layouts that cannot be always stretched to full width, and it should be only consistent width, which can break only 4(?) times. It makes easier to work with layouts, especially if you're working with more precise widths and consistency. You can check layout overflows, breaking changes, only at those 4 breakpoints.

For example, take GitHub, it also has a container of fixed width. Although it doesn't change at breakpoints, it still feels a better layout than if it would be always 100%. On big screens its hard to read information if everything stretches to full width.

And on smaller devices its easier to make design changes, by writing only 4 media queries, to change sizes etc., knowing that things may break only at these breakpoints, and you always know it.

Imagine creating a horizontal navigation bar (filter bar, whatever), where's logo, bunch of navigation items, inputs, and some icons, dropdowns etc.

Now you wrap it inside .container-fluid, then you start shrinking the browser window, it will break at some point, some items will be overflown to next line, when will it happen you don't exactly know. So you have to check manually each time resizing window and then making size adjustments in css, or hiding/showing stuff.

Now with .container, you have to worry only for 4 sizes, if everything's ok on example .lg screen, you know it will work from .md to .lg (from break-point to break-point) and you don't need to test multiple width sizes, only the other break-points. This is just an essential thing if working with device breakpoints. The meaning of .hidden-md-down etc. is gone. Because now you have to write custom breakpoints, for when things will break.

At least that's how I feel, and I've been using .container a lot, instead of .container-fluid.

For layouts using only .container-fluid its different. This is the only reasoning for .container.

Hope I explained it correctly.

TL;DR;

• Breakpoints less meaning.
• hidden-md-down etc. loses meaning.
• No layout consistency.

Also your proposition, if I understand correctly, merges the two current container behavior, so now on container will be 100% width, but will stop at large breakpoint. For me personally I have mixed feelings about this. No objective opinion here I guess.

[nextgenthemes]

To be clear I do not want this to understood my only goal with this is to remove the .container. Maybe I delete that, did not expect that to happen anyway but I think the .container-fluid should get more testing and get a max-width and should be used more in examples ...

If you would do layout for a newspaper I would get it but in CSS you cant really know the layout. Different fonts, user font settings ... all this are things where you cant know how it will actually display on a users screen. Text will flow differently, buttons will have different sizes because of that ... I not really see that point. At least the .fluid-layout should be more tested judging by the issue I references with the navbar its was not on the radar during design. Making fluid default would solve that.

I would get it for example if you want a sidebar with fixed sized images and you want that sidebar to stay the same width, something that is actually not possible with the BS grid system because there everything is based on percentages. I actually spend hours on coding up my own stuff because I was obsessed with fixed width sidebars but fluid content, but at this point I just went back to the BS grid because its all flexbox now.

For example, take GitHub, it also has a container of fixed width. Although it doesn't change at breakpoints, it still feels a better layout than if it would be always 100%. On big screens its hard to read information if everything stretches to full width.

I don't get what your point is, thats exactly why I am proposing a max-width for the fluid container. I do not argue for it in its current state.

Again I think people actually pick .container for 2 reasons, mainly because its default and 2ndly because its max with on big screens is limited. They not have in mind that it can be fluid but still have a max-width because BS never gives them the Idea. They see the fluid layouts as this unreadable full screen things, but they don't have to be.

Now you wrap it inside .container-fluid, then you start shrinking the browser window, it will break at some point, some items will be overflown to next line, when will it happen you don't exactly know. So you have to check manually each time resizing window and then making size adjustments in css, or hiding/showing stuff.

Well yes that exactly what I do, I leave a few pixels space to account for different font sizes or some text getting a big longer. I don't see much of a difference there between fixed and fluid layouts, in fact with the fluid layouts if something breaks your it may just be one rarely used screen/font size that is effected and its all gone as soon as the screen get a little bigger. With the fixed layouts, if you have something break out you will have it all the way up to the next breakpoint, that may be quite a lot of different devices. To me fluid layouts make so much more sense.

[ghost]

Well, adding more features to .container-fluid could be good, but please don't remove .container with its current break-point behavior 😃

[mdo]

So I actually do not get the point of .container with its fixed widths at all. Why does it exist? Whats the point?

As the docs outline, .container-fluid goes the full width of the browser and .container has a handful of fixed widths appropriate to common device and browser viewports. Two separate use cases and approaches to building page layouts, and not the only ways to do it either. We'll be keeping both, and not modifying the fluid container.

[nextgenthemes]

@mdo You not really explained what the purpose of .container is. What is the advantage of multiple fixed width in comparison for a .container-fluid-limited. I have not heard a single argument for this weird .container behavior that made sense. What was the initial idea behind this. Again, I have seen nobody use this kind of thing on real world websites, except those who use BS and just got tricked to use it that way.

.container-fluid and .container-fluid-limited would make sense. Two different purposes, perfect for all devices.

@DavisMiculis argument that its easier to design for multiple widths is actually not true, it actually makes no sense at all to me. I am still waiting for some actual provable advantage.