Grid breakpoint for 480px

[luaz]

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.

[andyl]

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

[ggam]

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

[puzrin]

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

[andyl]

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

[andyl]

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.

[luaz]

@andyl +1 for simple and safe

[heldchen]

+1

[ggam]

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

[puzrin]

@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

[andyl]

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

[ggam]

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

[heldchen]

@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

[ggam]

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

[andyl]

@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! :-)

[heldchen]

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

[ggam]

@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: https://github.com/twbs/bootstrap/blob/b86cd3bc3d866838127e7af15f665c70e7f50847/less/variables.less#L210) by adding a note instead of deleting, I thought no more BC-breaking was being accepted. But I can be wrong.

[heldchen]

@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

[andyl]

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

[igormalyk]

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.

[igormalyk]

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 ?

[jkins]

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

[mdo]

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.

[andyl]

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

[jkins]

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

[greggian]

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

[mdo]

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

[andyl]

@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! :-)

[luaz]

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.

[mdo]

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

[andyl]

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

[mdo]

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.

[andyl]

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

[andyl]

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

[michaelvandonselaar]

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

[andyl]

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

[luaz]

@andyl thanks. Will test this out.

[zzseba78]

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 !!

[andyl]

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

[zzseba78]

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

[andyl]

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

[zzseba78]

Thanks andy!

[junmuz]

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

[andyl]

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

[meecect]

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.

[ghost]

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;

[ghost]

É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

[intelligence]

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

[andyl]

@intelligence - can you post an example?

[intelligence]

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

[andyl]

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