twbs / bootstrap

The smallest grid column supported at the moment is .col-xs- (<768px), which seems like a big range.

Would it be advisable to have:
.col-xs- (>480px and <768px)
.col-tn- (<480px)

Reason being it still seems reasonable to have a 2 column grid on 768px (240px - 384px per column), while 480px have a stacked column.

Using the current .col-xs- (<768px) option, putting one stacked column on 768px seems too wide on some cases, and 2 columns on 480px seems ridiculous at times.

1000 times - please add .col-tn with breakpoint @ 480 - important to have more control for small-screen layouts.

You can always add your own breakpoint by customizing grid.less. The core can't provide solutions for every possible situation IMO.

+1. With great mobile support in 3.0, it would be nice to have one more breakpoint, to separate vertial mobile & horisontal mobile. 768px is too big for such split.

@ggam - the col-tn breakpoint is important for the use-case of rotating your phone from portrait to landscape. Everyone who targets phone devices with BS3 will encounter this problem. Its a core issue.

Yes I can add my own breakpoint. But my project involves 3rd party developers who write web components that rely on BS3 as the common UI framework. So now I gotta ask each of them to implement this col-tn hack, to take time to learn the workaround. Not good, especially for the framework that bills itself as 'mobile first'.

Here is a gist that adds a breakpoint between 480 and 768px. Instead of 'col-tn' as the smallest breakpoint, I added 'col-ms' ('ms' stands for 'mid-small') between col-xs and col-sm.

col-sm - (small) works at 768 +
col-ms - (mid-small) between 480 and 768
col-xs - (extra-small) less than 480px - same old class

I strongly believe this should be part of BS3. And col-ms is very simple and safe to add. If the maintainers give a thumbs up, I'll submit pull requests to update the Less files and the related docco.

@andyl +1 for simple and safe

+1

@andyl your use-case seems like a valid one. The problem is we already have 4 grid classes. Adding another one for 480px makes 5. It's a matter of time and people will start asking for a 1800px (or wathever else) breakpoint to support TV and extra-large devices.

If we are going to add more breakpoints, we will have to find a better way for that other than creating new modifiers. Otherwise we will end up with dozens of grids. Once #9970 or #10055 get merged, it will be really easy to add custom grids when needed.

@ggam since breakpoints have no conflicts, i don't see problems in increasing their count, when reason is significant.

PS. also, visibility classes should be extented

@ggam - dozens of grids? Nobody is asking for that. I don't want custom grids. I use BS3 because it provides sensible defaults that independent developers can use as a standard with no training or hand-holding from me.

I'm asking to add a single grid that addresses a critical use case for mobile development - rotating your phone from landscape to portrait. The CSS code is done, it is simple and has no conflicts with any other aspect of BS.

One-hundred percent of your mobile developers will encounter this use case. It would be a shame to force all of them to re-invent a custom grid. For the good of bootstrap, the 'mobile first' framework, I hope you will add this breakpoint.

@andyl Well, so convert your gist to LESS and find a better name for the breakpoint (maybe xxs?), cause using "medium-small" for a breakpoint that is smaller than "extra-small" doesn't make sense. Also, until push/pulls/offsets are added back to xs, I wouldn't expect them to be added to an even smaller breakpoint.
Also, would be nice if you can create the visible/hidden utilities and documentation to reflect the changes.

Then, create a pull request and wait for @mdo comments. I don't take decissions here, I only share my opinion.

@ggam you missed that the proposal is .col-xs << .col-ms << .col-sm << .col-lg << .col-xl

with the new col-ms having the current break-width of the current col-xs, and the new col-xs having a new breakpoint of 480px

@heldchen But that proposal cannot be accepted as it would break BC. Also, I'd prefer to see the new .col-ms as .col-sm, and col-sm renamed to col-md. I think it makes more sense.

@ggam & @heldchen - note that I propose no change to any existing grids - .col-sm and .col-xs would continue as-is. The new grid .col-ms imposes no change for existing applications, and nothing would break. Try it! :-)

@ggam 3.1 has other BC-breaking stuff planned, so what's not really a good reason not to think about it, is it?

@andyl what a mess on my side! Anyway, your breakpoint is filling the gap between "extra-small" and "small", so calling it "medium-small" doesn't really make sense for me. The only right way for me would be to rename some of the existing classes.

@heldchen can you give me an example please? Given the way they are treating deprecations (see variables.less:

bootstrap/less/variables.less

Line 210 in b86cd3b

// Note: Deprecated @screen-xs and @screen-phone as of v3.0.1

) by adding a note instead of deleting, I thought no more BC-breaking was being accepted. But I can be wrong.

@ggam i was under the impression that the screen-name variable will be gone by 3.1, but i can be wrong.

either way, .col-xxs for 480p would be a good name as well. sooner or later there will be a .col-xxl needed as well when the trend to larger pixel densities continues, so that would follow some consistent naming

@ggam - if I were the framework maintainer, I would be reluctant to break existing apps. That's why I proposed no changes to .col-xs and .col-sm. In my proposal, the classes would be xs < ms < sm < md < lg.

But if breaking changes are OK, I might go with xs < sm < md < lg < xl. This change would affect more CSS and docco, but is clearer and easier to understand (at least to me).

In any case, I believe this extra breakpoint is important. I'll submit pull requests if you (or whoever) gives the go-ahead.

Hello everyone. I've just started a new project with BS3 and I totally like it.
However as many others I was looking for the option to control small sized phone screens under 480px. Unfortunately as of time of writing the smallest option is 768px which is not enough. It could be added manually but I believe it should be added to the default set of breakpoints because a lot of people are looking for it.

In any case, I believe this extra breakpoint is important. I'll submit pull requests if you (or whoever) gives the go-ahead.

@andyl Why the pull request could not be submitted without a go-ahead ?

@ggam 3.1 has other BC-breaking stuff planned, so what's not really a good reason not to think about it, is it?

@heldchen Could you please share what stuff is planned for the 3.1 ?

+1, needed this exact case today in a new BS3-based app. Looks like we'll be maintaining a local patch and custom build 'til 3.1.0.

the col-tn breakpoint is important for the use-case of rotating your phone from portrait to landscape.

I don't really see this being an important or critical use case, @andyl. I think you're placing too much emphasis on folks rotating their devices. Without some sort of data—although I have no idea where we'd get it—I don't see any validation for this argument.

Beyond that, adding another tier to the grid system takes something that's already rather complex and makes it that much more complicated. With another tier we'd likely have to add offsets, pushes, pulls, and responsive utilities. That's a lot of code to add.

@heldchen We don't have any backward compatibility breaking changes planned for v3.1.0.

i was under the impression that the screen-name variable will be gone by 3.1, but i can be wrong.

@heldchen We've deprecated @screen-{device} for @screen-{size} as a means of being more consistent in our code. Nothing has been strictly removed. All those device variables are still there, just assigned to the size ones. For example, we document and use @screen-sm instead of @screen-tablet for our .col-sm-* grid columns.

For the time being, I don't see a convincing set of reasons to do this.

@mdo - it's absolutely not a lot of work for pushes/pulls - the code is written and its very simple - see for yourself! Everyone who uses BS3 for small devices is gonna encounter this issue, and it would be a shame to make all of them hack their own custom solution.

I think landscape orientation should be accounted for in any mobile project, and the proposal seems reasonable; 480px was the portrait length of the first three generations of iPhone, and it was the portrait width of some phones as recent as the Galaxy S II. But this would also be useful for the smaller tablets, and smaller browser windows/frames.

For my shop, it would be a welcome increase in the "responsive resolution" of the grid. It would be unfortunate for us to be unable to use the responsive functionality of it, ironically due to not reaching the minimum targeted resolution...

@mdo I went looking for stats based on your request. StatCounter has some stats on mobile device resolutions for reference. To me, this seems to suggest that there is a fair amount of range below 768px that devs/designers might want to specifically support.

full disclosure: I too have been silently watching this issue, hoping it might be implemented in the near future.

@andyl I never said it was a lot of work—I said it was a lot of code. More than anything it's just a few minutes of copy-pasting and then maybe an hour of updating some things in the docs. The bulk of the effort would be in the docs.

The emphasis folks area placing on landscape is greater than I think folks are making it out to be. That aside, I fully understand the number of devices under 768px wide, and that 480px to 768px is a decently wide gap, and an important one. However, implementing this would change the behavior of our grid system, and that can't happen until v4.

To elaborate, here's what we'd likely have to do to make this work:

Add a new grid tier, say maybe just .col-*. It'd be unbound to any media query, min- or max-width, just like the .col-xs-* classes today.
Bump up the xs tier to be min-width: 480px. sm, md, and lg would stay the same.
Add not only .col-1 through .col-12, but at least .col-push-1 to .col-push-12 and .col-pull-1-.col-pull-12. Beyond that, we'd also need to (or be expected to) add .col-xs-offset-0 to .col-xs-offset-12, .col-xs-push-0 to .col-xs-push-12, and .col-xs-pull-0 to .col-xs-pull-12.
Update all our documentation, including tables, snippets, and examples.
Add another tier of responsive toggles because folks will want it.

That is a decent amount of work, but again that's not the hold up at all. The hold up is that this changes the behavior of one of our current grid tiers, that being .col-xs-. In other words? It's backwards incompatible. No matter how you cut it, that tier would have to change to account for a min-width. To not do that would just be even more confusing (say if were to implement .col-tn- with a max-width). We don't do anything like that elsewhere.

Bottom line, we can't. Not until v4, if we do opt to go this route.

@mdo - my proposed change leaves existing grids untouched, and just adds a new grid in the gap between xs and sm. As explained earlier in this thread, the advantage of this approach is that it is backwards compatible - it forces no change for current users, and breaks no existing apps.

The code for the new grid is ~100 lines long and includes all of the push/pull/offset classes you mentioned. Check it out! :-)

I believe this feature shall be an uphill battle: some thinks it is basic essential feature, others think it's a luxury. I thought it could be coming in 3.x, seems like I am wrong.

Plan B
@andyl would it be too much to ask for a CSS file for this feature which I can include it and make it work today (I apologize for my lack of skill in LESS/SASS stuff).

PS: I was showing my new BS3 page to a friend to show how responsive it is, and he asked, "So if I switch the Phone to landscape mode the layout will change to 2 column right?" I don't have the heart to tell him BS3 doesn't support this.

@andyl I see the difference—my bad, forgot to address that part. Even with injecting another tier of the grid between two existing ones, it does effectively break backward compatibility in that it changes the behavior of the grid system and responsive utilities. What used to apply to one range not doesn't apply to a subset of that. I don't think we can get away with it.

@mdo - "it changes the behavior of the grid system and responsive utilities" - I truly believe that the new grid does not change the behavior of existing code, and does not break backwards compatibility in any way. If I'm wrong about that, I'll eat my hat. :-) I've been using the new grid for the past week and haven't run into any problems.

Right now there is a grid tier that spans 0 to 768px. You're proposing to add one that spans 480px to 768px. Without diving in anymore than that, you're changing the behavior of the grid system. That's enough to call this moot.

Beyond that, you're changing the responsive utilities that go with the grid tiers. The range of widths affected by .hidden-xs changes with the addition of .hidden-ms, per your example. That's a breaking change in addition to the change in behavior of the grid system.

The smaller tier makes sense—I get that. But this cannot be done without breaking or changing something.

@mdo - the grid-system media selectors trigger off min-widths, not from a range. Therefore, if you don't use the new grid, there is no change to the grid system, and existing apps can not break. The grid behavior only changes if you explicitly use the new grid classes.

Note that .hidden-ms is not part of the proposed grid - I didn't propose any new responsive utilities.

@luaz - re:Plan B - here is a gist for the new grid rendered in CSS. You can use this CSS in your existing app - give it a try!

@andyl - I think you want to put a max-width: 767px on your media query to prevent .container max-width breaking existing layouts

@michaelvandonselaar - I think you are right - I updated the css and sass - thanks for the tip.

@andyl thanks. Will test this out.

Hi, i´m new in bootstrap 3, think it´s amazing but i need to implement your hack since i have to creat a breakpoint in 480px and <768px, . Can you explain how to implement the andy´s hack? Like i said, i´m new in bootstrap and have the css/ js folder only. I downloaded the full version of Bootstrap, check que grid.less file but don´t know how transform this to css js code ready for use.
Thanks !!

@zzseba78 - just include the CSS in your project, then the .col-ms-* classes, push/pull/offset classes can be used just like the other BS grid classes. (lg/md/sm)

Perfect, works great! I see that the .hidden and .visible classes for this new break must be created...

@zzseba78 - right - there are no hidden/visible classes - you'll have to create those yourself.

Thanks andy!

@andyl, I am a newbie to using sass. I have failed in using your addon to my bootstrap.css file. I am getting error

Syntax error: Undefined variable: "$grid-gutter-width".
on line 38 of bootstrap_ms.css.scss

I am using saas version 3.2 and bootstrap version 3.0.

Thanks.

@junmuz - check the ordering of your SASS imports. You gotta import bootstrap_ms after bootstrap.

I would love to see this in core. A common use case (for us anyway) is a simple grid of images. At a wide resolution, there may be a sidebar and then 4 columns of images (col-md-3, say). The problem is, as the screen width decreases, it quickly becomes col-xs-12, or just images stacked on top of each other.

Since we use img-responsive, the images scale, but that means that at 768px wide, the image has to scale all the way up to nearly 768px wide, since it spans the whole row.

That in turn means that on wider screens, when 4 columns will fit, each image is only maybe 175px wide, which is fine.

This means that we either choose to have col-xs-6, and cram 2 columns inside a portrait iphone, or we make all of our source images 4 times wider than they really need to be so that they look 'ok' when on the smaller device.

Sass. Kudarcot vallottam be a addon az én bootstrap.css fájlt. Én szerzés hiba:@ Brand-figyelmeztetés: # f25d18;@ Szürke sötétebb: # 222222;@ Brand-figyelmeztetés: # f25d18;@ Border-radius-nagy: 12px;

Én használ SaaS verzió 3.2-es és 3.0-s verzió bootstrap.Én használ SaaS verzió 3.2-es és 3.0-s verzió bootstrap.többet, mint, hogy te magatartásának megváltoztatásában a távvezeték-rendszer ... Col-xs-pull-12

@andyl Thanks for the pure css document. I included it my app.css (loaded after bootstrap). But now col-sm-* is overtaken by col-ms-* (at sm, md and lg viewport sizes obviously). Why's that?

@intelligence - can you post an example?

@andyl http://optomore.com/
U: admin
P: dev

The text beginning with "Gustaf Ryding" is sm-8 and ms-10, but ms-10 overrides sm..

@intelligence - I had a quick look at your example - thanks for posting. It wasn't immediately obvious what was going on.

Sorry but I am overloaded between now the end-of-year - won't have time to diagnose this issue for awhile. I'll come back to it when I have some breathing room. Your page looks great so hopefully this won't cause too much problems in the near-term.

@andyl I'm sure I'll manage. Thought I was doing something wrong but now I can maybe rule that out. Thanks for having a look :)

@intelligence the problem is that importing @andyl css after bootstrap will have the .col-ms- override the bigger classes. If you just change the media query on bootstrap_ms.css line 18 from:

@media (min-width: 480px)

to:

@media (min-width: 480px) and (max-width: 768px) {

then .col-ms will not override -sm or any of the bigger col classes.

remember bootstrap_ms.css gets imported after bootstrap

Is there a less version of this? I want to add it.

Actually, since I've been doing mobile first since 2011, I've opted for mobile first ONLY if shared classes, otherwise max-width is used since using important! to override classes inside a min-width is really annoying among other things. Mobile first, when it began, was intended to target screen readers who can't read media queries as well as keep the mobile site from getting all the floats and stuff that it won't use anyway, but loading up the min-width with !importants and having to go mobile first even if it hurts is just silly. Just my two cents.


@media (min-width: 480px) and (max-width: 767px) {

Never mind. I added it in the .make-grid-columns and in the grid.less and it works so well!

@andyl Thanks for sharing your addition to the default BS3 grid. I ran into this exact issue designing a new site and was sort of flabbergasted it wasn't considered a basic use case. I'm not sure why the landscape view is getting the short shrift (aside from simply reduced complexity), but I definitely agree this use case will be encountered by a lot of people.

@andyl thanks for your code and convincing effort. Your class col-ms does overwrite the bootstrap classes for bigger devices.

@eddieferrer if you set a max width, the layout gets back to the small layout above break point.

I have to agree on an additional breaking point in the grid. Bootstrap comes with the promise of being mobile first in 3.0 and than does not have a break point until 768px? This makes the mobile first approach almost impossible to implement. The smaller the screen size the more important the breaking points.
Bootstrap offers a lot of fantastic tools and I really like it, but this new break point is a must and should be added in as quickly as possible.

In Andy's Gist https://gist.github.com/andyl/6360906 if you are using the SASS version change

@media (min-width: $screen-xs) { .container { @media (max-width: $screen-sm ) { max-width: $screen-sm - 20px; } }

to

@media (min-width: $screen-xs) and (max-width: $screen-xs-max) { .container { max-width: ($screen-sm) - 20px; }

If you are using LESS version change to

@media (min-width: @screen-xs) and (max-width: @screen-xs-max) { .container { max-width: (@screen-sm) - 20px; }

then mostly everything turns out fine. Thanks to @andyl for your work on this, I agree, it's totally essential, nevermind what those hipsters from SF say. ;)

Thank you andyl! That's really strange that the bootstrap team, instead of implementing this suggestion for improvement, closed this. Seriously: I'm building a responsive page and I need a good design between 480 and 768 (for users who like to resize a window -I don't think that all desktop users like to have a full screen browser-, or if the page is included in an iframe). This "hack" is the best I've found so far. OMO you should implement it in bootstrap 3.1... anyway, good thing of open source is to fork a project and make a new one... or add "hacks" like this ;)

If somebody needs this: I updated the css as suggested by michaelvandonselaar (767px) and by eddieferrer: https://gist.github.com/firepol/7942411

Thank you andyl! That's really strange that the bootstrap team, instead of implementing this suggestion for improvement, closed this.

@firepol Did you bother to read the comments explaining how backwards compatibility prevents us from implementing this at the present time?

@firepol, @cvrebert and future readers - the only person who reported an incompatibility with col-ms was @michaelvandonselaar, and his fix has been applied and tested by a lot of people. So at this point, there is no backwards incompatibility, nothing that prevents col-ms from being added to 3.1.

Yeah, it's really excellent. Though I incorporated into the grid.less and the mixin.less so updating is a little annoying since I have to paste that back in each time but it's not a big deal. Iff anyone has ideas on how to stick it somewhere else, that would be great.

I my grid.less

// Medium Small grid (added) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
//
@media (min-width: 30.000em) and (max-width: 47.938em) {
  .make-grid-columns-float(ms);
  .make-grid(@grid-columns, ms, width);
  .make-grid(@grid-columns, ms, pull);
  .make-grid(@grid-columns, ms, push);
  .make-grid(@grid-columns, ms, offset);
}

in mixins.less

// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Generate the medium small columns
.make-ms-column(@columns; @gutter: @grid-gutter-width) {
  position: relative;
  // Prevent columns from collapsing when empty
  min-height: 1px;
  // Inner gutter via padding
  padding-left:  (@gutter / 2);
  padding-right: (@gutter / 2);

  // Calculate width based on number of columns available
  @media (min-width: @screen-ms-min) {
    float: left;
    width: percentage((@columns / @grid-columns));
  }
}

// Generate the medium column offsets
.make-ms-column-offset(@columns) {
  @media (min-width: @screen-ms-min) {
    margin-left: percentage((@columns / @grid-columns));
  }
}
.make-ms-column-push(@columns) {
  @media (min-width: @screen-ms) {
    left: percentage((@columns / @grid-columns));
  }
}
.make-ms-column-pull(@columns) {
  @media (min-width: @screen-ms-min) {
    right: percentage((@columns / @grid-columns));
  }
}
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Generate the medium small columns

and (I had to put the position:relative on the min-width since my equal column script didn't work when it was before.

// +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NEW COLUMN MEDIUM SMALL ADDED
// Framework grid generation
//
// Used only by Bootstrap to generate the correct number of grid classes given
// any value of `@grid-columns`.

.make-grid-columns() {
  // Common styles for all sizes of grid columns, widths 1-12
  .col(@index) when (@index = 1) { // initial
    @item: ~".col-xs-@{index}, .col-ms-@{index}, .col-sm-@{index}, .col-md-@{index}, .col-lg-@{index}";
    .col(@index + 1, @item);
  }
  .col(@index, @list) when (@index =< @grid-columns) { // general; "=<" isn't a typo
    @item: ~".col-xs-@{index}, .col-ms-@{index}, .col-sm-@{index}, .col-md-@{index}, .col-lg-@{index}";
    .col(@index + 1, ~"@{list}, @{item}");
  }
  .col(@index, @list) when (@index > @grid-columns) { // terminal
    @{list} {
      // position: relative; // +++++++++++++++++++++++++++++++++++++++++++++++++++++++ this prevents equal heights, put it on the min-widths instead
      // Prevent columns from collapsing when empty
      min-height: 1px;
      // Inner gutter via padding
      padding-left:  (@grid-gutter-width / 2);
      padding-right: (@grid-gutter-width / 2);
    }
  }
  .col(1); // kickstart it
}

.make-grid-columns-float(@class) {
  .col(@index) when (@index = 1) { // initial
    @item: ~".col-@{class}-@{index}";
    .col((@index + 1), @item);
  }
  .col(@index, @list) when (@index =< @grid-columns) { // general
    @item: ~".col-@{class}-@{index}";
    .col((@index + 1), ~"@{list}, @{item}");
  }
  .col(@index, @list) when (@index > @grid-columns) { // terminal
    @{list} {
      float: left;
      position: relative; //+++++++++++++++++++++++++++++++++++++++++++++++++++++ added here so that equal columns works
    }
  }
  .col(1); // kickstart it
}

+1

I agree there is a missing breakpoint - and it's not even a problem restricted to portrait vs. landscape.

Some 'phones' (phablets?) are huge now - and a single column which might look OK on an iphone looks ridiculous on a 720 width Samsung Galaxy.

At the moment BS does not have an inbuilt breakpoint for this so I am using this workaround - thanks to @andyl @michaelvandonselaar, @eddieferrer and @firepol for your solutions.

Really this isn't even an option out of the box!! It seems really self-evident that a break-point below 780 (or whatever it is) is needed. xs is at 780!? It looks terrible when you have to do a single column at that large width... It doesn't even seem like it would be that difficult to implement. I wonder why the team is being so difficult on this one...?

There is no need to be upset @redorlee. As numerous folks have mentioned, it's straightforward enough to add the extra break point if you want it. And I've explained our point of view on this a few times over now. I suppose one more time won't hurt.

This change affects the behavior of the grid system.
With every grid tier comes the appropriate container width and responsive utility classes.
Changing the behavior of the container (not even the columns) for a subset of a current grid tier sounds like us throwing a major curve ball to the majority of folks.
Adding the columns isn't the problem—doing something misleading or half-implemented is. We won't add another tier without proper documentation, responsive utilities (and associated tests), or container.

It's not a matter of us being difficult—we're trying to not screw over lots of folks who might not see this coming as it does appear to be a potential breaking change.

@mdo - the Bootstrap team keeps insisting that the col-ms class changes the behavior of the grid system. That is not correct. If you look closely at the original col-ms class, and the tweak suggested by @michaelvandonselaar , you'll understand that col-ms does not change the behavior of existing apps in any way. At this point, lots of people have tested the solution.

There is still demand for an off-the-shelf breakpoint for mobile devices, months after the issue was closed. The col-ms breakpoint is really simple, and I hope it will be included in Bootstrap 3.1 !!

@andyl What about the .container—just ignored it and go full-width? And the responsive utilities? And documentation to support it all? We won't be implementing another grid tier half-way.

@mdo - three people have posted .container solutions on this thread ( @michaelvandonselaar, @eddieferrer and @brgrz ) I think any of them will work. Responsive utilities (visible-ms and hidden-ms) aren't written - but I could do that if you like. Docco - yeah - I could write that too (grid options and responsive utilities).

@mdo If the problem is completeness, why not mark it as an open item with a targeted milestone. I think the thing that is frustrating a lot of people is the fact that it is closed which doesn't convey that it won't be done unless complete, it conveys that it won't/can't be done at all. If you're indeed saying it won't/can't be done at all, it seems very short sighted. If you're not saying it won't/can't be done, then please open it back up so that users can at least be relatively aware of this issue.

@andyl The .container no longer uses max-width though, and I'm still unclear how that doesn't change the behavior of the grid. Adding another breakpoint to the .container that changes the width will affect everyone, not just those wanting to use this new tier, right? See https://github.com/twbs/bootstrap/blob/master/less/grid.less#L6:L22.

And if we wanted to add the responsive utilities, that changes the other responsive grid utilities—or at the very least creates some overlap, right?

The 480 - 767px is a min and max for this and it doesn't overlap, so the responsive utilities wouldn't overlap since they're inside the same, right?

@carasmo Right now, the xs responsive utilities span 0 to 767px. Adding the proposed ms classes would range 480px to 767px. Either they overlap, or the xs utilities are rewritten to not interfere (can't do until v4).

@mdo - if you don't use the col-ms class, then col-xs continues to operate as normal, and existing apps would notice no change. Having said that - it seems like col-ms isn't going to happen for 3.1. That's unfortunate but not the end of the world - the hack will still work.

Having said that - it seems like col-ms isn't going to happen for 3.1.

Who said that? v3.1 won't drop until early January. My only reservations are that this is an incomplete implementation (responsive utilities) and that this also affects .containers for folks who don't use the new classes. It's also a little confusing given how the existing grid system tiers work, but the right example and docs to support it would likely eliminate most of the confusion.

If those items are addressed, we can likely get this in for the release. As of this moment though, I'm still not convinced this doesn't break something in the existing code base and grid system behavior.

So far, simply using it (without any responsive utilities) has been great. There's been no issues at all.

Dear all, I think I understand @mdo point of view that this ms feature, to be properly implemented, will require a bit of work and testing (this is true for every improvement...). @andyl (thx again man for posting your css!) and some other people tested it, and saw no problem in using the ms "hack". I also tested it and I can post here my little contribution in the discussion. I created a little tool to send e-cards (feel free to use it). I wanted the form to look nice also between 480 and 768 px, so the "ms" hack came handy for this purpose.

Please compare yourself:

form without ms hack: http://test.pbworks.ch/ecard-no-ms

form with ms hack: http://test.pbworks.ch/ecard-ms

Resize the window, so that the window width will be less than 768px, but more than 480px. I personally don't like the "no-ms" (standard bootstrap) version: as soon I make my browser window smaller than 768px -even if the screen has full of available space- I get the ugly form made for mobile devices. I really don't like it: I'm on desktop, doesn't mean I browse with a full screen window all the time (especially having a big screen with a big resolution, something quite normal for many people in 2013).

On the other hand, on my mobile device (Samsung Galaxy S3), when I browse the web in landscape mode, the form with the ms hack look nicer than the original bootstrap one (even my girlfriend confirmed so) and saves me from scrolling down. Yes I know that people are used to scroll and scroll on mobile. Doesn't mean they have to do it for every form on the web...

The only difference (maybe it's wanted so, and not an issue) I noticed: the form labels in the ms solution are not aligned on the right. @andyl, @carasmo ideas? Maybe my css doesn't contain some last improvements you did, or as mdo mentioned, some responsive css are missing... if so let me know and I can update the css in the "ms" page. As said, to fully implement this ms solution, some more hours of work are needed. Let's do it!

We have the power to make the web a better place and to give people a nice user experience. I really hope that the ms solution will be implemented in bootstrap soon. Thank you.

The .form-horizontal .form-group .control-label is only text-align: right at the min-width, so it's up to us, the users of this addon to add the appropriate css inside the col-ms media query. Might work:

.form-horizontal .form-group .control-label {text-align:right;}

@carasmo thank you. CSS updated: https://gist.github.com/firepol/7942411

Also the form looks better: http://test.pbworks.ch/ecard-ms

This feature is so essential, please make it in 3.1 release

PLEASE add another breakpoint below 768... this is really needed!!!

I just wanted to throw in my hat saying that we are running into this exact issue with the bootstrap grid on the product I'm working on. I would really love it if you guys would consider adding another size to more specifically target smaller devices in a future release.

Well i tried to add less but somehow it breaks the grid system.. I have done another quick fix that works for me...
i use a custom .ms class along with col-xs classes to maintain columns no matter what and set a specific breakpoint for .ms say 600px and make them width:100%

@media (max-width: 600px) {
  .ms {
    width: 100%;
    float: none;
    display: block;
    min-height: 1px;
  }
}

I cannot believe 480 breakpoint isn't still implemented. What a shame for BS developers. :S

Easy enough to add on your own in a few min.

Easy enough... but multiply the work by thousands and you got a lot of wasted hours...
+1 for adding this to BS

Bootstrap Team: add 480 breakpoint and you will achieve almost perfection! :)

Read the comments and you'll understand why we haven't yet.

@mdo I cannot believe that you think one breakpoint is enough for 0-767px. 767px for one break point!!??

If its logical, why bootstrap then doesnt have this approach:
/* Small devices (tablets, 768px and up) */
@media (min-width: @screen-sm-min) { ... }

/* Medium devices (desktops, 1536px and up) / / 768 + 768 */
@media (min-width: @screen-md-min) { ... }

/* Large devices (large desktops, 2304px and up) / / 768 + 768 + 768 */
@media (min-width: @screen-lg-min) { ... }

Is this logical? You obvious doesn't know that mobile devices has two orientation, and that good UE is to show different layout for different orientation. So every logical developer will do something like this if adding new breakpoint has impact on performances:

/* DEFAULT : MOBILE UPTO 479px */

/* Small devices (tablets, 480px and up) */
@media (min-width: @screen-sm-min) { ... }

/* Medium devices (desktops, 768px and up) */
@media (min-width: @screen-md-min) { ... }

/* Large devices (large desktops, 1200px and up) */
@media (min-width: @screen-lg-min) { ... }

@dezio1900

Add it yourself.

This is a free, awesome, framework. I don't understand why, when we change fonts, colors, and various other things, we can't take, literally, a few more minutes to add the breakpoint ourselves until it's been tested and added into another iteration in the near future.

Its not a big problem for me to add it by myself. Problem is that BS developers doesn't want to confess that they are making a mistake by ignoring mobile devices. Maybe they only use tablets and desktops, but they must admit that mobile devices are also important. Responsive design isn't really responsive if we don't have 480 bp.

I just cannot believe that someone thinks that layout for 320px and 480px+ should be the same...

There's no confession required, they don't owe us diddly squat. 767px is and was a common breakpoint to start stacking, and when the need arises for use of something between there, roll it yourself.

I think we need to digg into "Media queries breakpoints", 4 breakpoints it´s more than enough, first time i set breakpoints the grid breaks up ( i set it wrong :) ), but with some tweaking it gets right. Bootstrap is awesome, works great, it´s simple, it´s clean, and IT´S FREE. Let's not complain so much, these people do a great job. Cheers from Uruguay ( country of legal marihuana :) )

I get you can't add every possible device breakpoint, but the lack of a 320px breakpoint is surprising.

@mdo I cannot believe that you think one breakpoint is enough for 0-767px. 767px for one break point!!??

I just cannot believe that someone thinks that layout for 320px and 480px+ should be the same...

@dezio1900 On the contrary, I definitely want to support it, and I've made that quite clear. However, I cannot in good faith change the behavior of .containers and responsive utilities for folks who haven't accounted for this new breakpoint in their code. The potential for broken code is quite high. You'd know that if you read my previous comments, as I asked you to earlier.

Is this logical? You obvious doesn't know that mobile devices has two orientation, and that good UE is to show different layout for different orientation.

You assume ignorance on my part when you haven't spent a fraction of the time I have with this, or any other part of Bootstrap. You're also making broad and inaccurate statements about several topics. There is no one perfect solution for everyone.

Problem is that BS developers doesn't want to confess that they are making a mistake by ignoring mobile devices.

As the very kind and helpful @carasmo has mentioned, there is no confession to be made. Once again, you assume ignorance on our part, and on top of that you add malice—as if we intentionally want to make your life more difficult.

Maybe they only use tablets and desktops, but they must admit that mobile devices are also important.

One more time, read my previous comments. We want it, but cannot do it until v4.

Responsive design isn't really responsive if we don't have 480 bp.

Says who? Again, every project is different.

I get you can't add every possible device breakpoint, but the lack of a 320px breakpoint is surprising.

@chrisabrams I'll tack this reply on here as well—read my previous comments, and perhaps the entire discussion here. It cannot happen without changing the .container and responsive utilities for the surrounding breakpoints, and that breaks backward compatibility.

Ok, sorry for not reading all replies from you. Its a good thing if you plan to implement this in v4.

Just cannot figure out why BS needs to be backward compatible? If I use BS 3 for one project, why would I update BS for that project? If I am starting a new project, I will use latest BS, so I cannot figure out why is backward compatibility so important.

Just cannot figure out why BS needs to be backward compatible?

@dezio1900 When your code is used by millions of people, version control and backward compatibility are pretty important.

Thanks @andyl and others for inspiration. Here you have the pull request for HS breakpoint at 480px (Horizontal Small, not ms, because it can be confusing with sm breakpoint) #12586
This is a less modification that you can customize with your needs. Includes col-hs, col-hs-pull, col-hs-push, col-hs-offset, container, visible-hs, hidden-hs
@mdo, I understand your decision about not include this to current master (for compatibility), but you have the code for next version you consider to include (maybe 4.x).

@mdo The only BC argument so far has been the .container.
Imo, we don't need to do anything about the container. Let the container width continue to be fluid-width 0-767px, as it is today. If we get a new .col-smaller-* (or ms, tn, etc) with min-width 480, that should be enough to make most people happy I imagine.

To make this feel more "right" for stuff involving max-width:
To not break BC, we should regard newly added ranges as subdivisions of the existing ranges.
So, xs still means 0 - 767 or 0 - *, depending if you are interested in max-width or not.
But there can be new sub-ranges:

xs = 0..767 or 0..*
xs-A = 0..479 or 0..*
xs-B = 480..767 or 480..*
sm = 768..991 or 768..*
md = 992..1199 or 992..*
lg = 1200..*
lg-A = 1200..1599 or 1200..*
lg-B = 1600..*
This could be A, B, C, .. instead of just A, B.

Obviously, as soon as we introduce one such a new breakpoint, we jam the door for future breakpoints. E.g. if we introduce xs-A and xs-B but then recognize we want an xs-C, this will be no longer possible. Instead, we could introduce an xs-B1 and xs-B2 to further subdivide xs-B.

If anyone wants the bootstrap.css from the above PR for download:
https://github.com/donquixote/bootstrap-compiled/tree/xs-AB-subdivision

Grid breakpoint for 480px