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

Add .no-gutters option to remove gutters from rows #21211

Merged
merged 1 commit into from Nov 26, 2016
Merged

Add .no-gutters option to remove gutters from rows #21211

merged 1 commit into from Nov 26, 2016

Conversation

mdo
Copy link
Member

@mdo mdo commented Nov 26, 2016

This branch adds .no-gutters to the predefined grid classes (meaning it can be removed if you disable the grid classes). It includes docs for how it's built in the source Sass and how to use it with a quick demo. This was one of the biggest feature requests for v4, so getting it in there with relatively few lines of code added was a no brainer.

Fixes #19107.

screen shot 2016-11-26 at 11 08 51 am

@mdo mdo added this to the v4.0.0-alpha.6 milestone Nov 26, 2016
@mdo mdo merged commit ec5e7e5 into v4-dev Nov 26, 2016
@mdo mdo deleted the no-gutters branch November 26, 2016 20:13
@Igcorreia
Copy link

Igcorreia commented Nov 28, 2016

Please consider adding it to the container itself:

Please consider adding:

.no-gutter.row,
.no-gutter.container,
.no-gutter.container-fluid{
margin-left: 0;
margin-right: 0;
padding-left: 0;
padding-right: 0;
}

.no-gutter>[class^="col-"]{
padding-left: 0;
padding-right: 0;
}

Otherwise we cant get a 100% fullscreen.

@mdo
Copy link
Member Author

mdo commented Nov 29, 2016

I'd advise you not to use the container if you want 100% width. The containers are there for a reason—horizontally pad the contents of the page and sometimes center it. Since you don't need it for .no-gutters, remove it outright instead of overriding it.

@Igcorreia
Copy link

Igcorreia commented Nov 29, 2016

@mdo so should be .row directly? :) It didn't crossed my mind. It did the Job! Don't consider my suggestion. If this goes forward we only need in the docs how to do a 100% responsive section.

Working Example

@IamManchanda
Copy link

IamManchanda commented Dec 7, 2016

containers are not for 100% width ... instead fixed width as per device size ( media query ) . Just there to take a fixed and neat width ( center aligned ), specially used for written material ( content ).
container-fluid are there for a full width but also has a padding right and left of 15px each, specially used for written material ( content ) that takes up the full screen.
sections are there for 100% width of the screen. specially used in the backgrounds

.row.no-gutters is enough i guess . no need for including container, container-fluid or section just nest them around as per requirement. For eg..

  1. If you are looking for a center aligned fixed width, nest the row within a container
  2. If you are looking for a full screen but with a tiny left and right padding, nest the row within a container
  3. If you are looking for a 100% full screen with no padding, nest the row within a section

@Igcorreia
Copy link

@IamManchanda thanks, is clear now. Youe description should go on the DOCs in my opinion.

@IamManchanda
Copy link

ohk then go ahead and make a Pull request @Igcorreia ... i will surely won't mind ... lol

@gdevany
Copy link

gdevany commented Mar 5, 2017

@IamManchanda Thanks for the explanation of section/row used for 100% width. You ended my hair pulling trying to fix the 'phone view' bottom scrolling issue by nesting row within section instead of nesting row within container (at width: 100%).

@IamManchanda
Copy link

@gdevany i am happy i saved your hairs 😄

@bananatranada
Copy link

bananatranada commented Jul 8, 2017

@mdo Apologies, but I still don't understand the reasoning behind keeping the container's padding.

An extremely common scenario is a navbar that takes advantage of bootstrap's max-width depending on the screen size. This obviously leads me to conveniently use a container.

However, when the screen size allows the navbar edges to touch, the left logo link and the right hamburger menu cannot reach out to the very edges (without additional styles). This may work for some designs where the logo and hamburger menu don't have to be in their exact corners, but this isn't always the case (e.g., stripe.com. The hamburger menu would look awkward if it weren't precisely in the corner. Not everybody may think this way, but my point is that the choice to keep container's padding is somewhat inflexible). In addition, the logo and menu links cannot take advantage of extra space on the edges because of the container's padding (again, without additional styles).

I may be wrong here, but isn't the main reason why containers have paddings in the first place because columns can act like containers when nested? This makes for a more consistent pattern to design and code with. For the same reason, I believe that if columns don't have padding, the container shouldn't either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants