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:

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.

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

[aakilfernandes]

Anyone have a way to do this without a precompiler? Some of us dummies still use vanilla CSS

[aakilfernandes]

For those interested: Foundation uses a breakpoint of 640 http://foundation.zurb.com/docs/components/grid.html

[Jakobud]

One simple reason why 768px is too big for the smallest breakpoint:

Google Nexus 7 Tablet

It's the #1 most used Android tablet in the world. And it's (css pixel ratio equivalent) portrait width is 600px (603px in the 2012 version). So you have a 7" tablet, that you are forced to see a mobile (xsmall) layout, which is quite awkward on such a big screen.

Foundation has the same problem as their smallest breakpoint is still 640px.

+1 for adding a 480px breakpoint to Bootstrap.

[outdoorsman]

I totally agree!

[Jakobud]

Is this thing going to get added before 4.0? Because I assume 4.0 is probably 9+ months away.

[cvrebert]

@Jakobud Nope. Read the prior comments for why.

[grandfatha]

I think everyone agrees that the breakpoint is necesary, but it is also been clarified that such a change will not occur in a point release. In the meantime, the only way is roll the hotfix above on your own. Might be nice to add a link to the grid documentation or have another example demonstrating this like the sticky footer stuff.

[Jakobud]

Okay, looking forward to this change. I see the gists above for adding in some preliminary 480px support, but is there a non-official branch of Bootstrap that supports it anywhere?

Also, in the current version, how come _variables.scss still contains references to screen-xs? Was it left in there on accident? I see it still used in _responsive-utilities, _tables and _navbar. Why is this stuff in there in the framework doesn't support that breakpoint? Maybe I missed the conversation on this so I'm a little confused.

//== Media queries breakpoints
//
//## Define the breakpoints at which your layout will change, adapting to different screen sizes.

// Extra small screen / phone
// Note: Deprecated $screen-xs and $screen-phone as of v3.0.1
$screen-xs:                  480px !default;
$screen-xs-min:              $screen-xs !default;
$screen-phone:               $screen-xs-min !default;

// Small screen / tablet
// Note: Deprecated $screen-sm and $screen-tablet as of v3.0.1
$screen-sm:                  768px !default;
$screen-sm-min:              $screen-sm !default;
$screen-tablet:              $screen-sm-min !default;

// Medium screen / desktop
// Note: Deprecated $screen-md and $screen-desktop as of v3.0.1
$screen-md:                  992px !default;
$screen-md-min:              $screen-md !default;
$screen-desktop:             $screen-md-min !default;

// Large screen / wide desktop
// Note: Deprecated $screen-lg and $screen-lg-desktop as of v3.0.1
$screen-lg:                  1200px !default;
$screen-lg-min:              $screen-lg !default;
$screen-lg-desktop:          $screen-lg-min !default;

// So media queries don't overlap when required, provide a maximum
$screen-xs-max:              ($screen-sm-min - 1) !default;
$screen-sm-max:              ($screen-md-min - 1) !default;
$screen-md-max:              ($screen-lg-min - 1) !default;

[donquixote]

@aakilfernandes Since you asked if this can be done without a precompiler:
You can simply download the bootstrap.css from https://github.com/donquixote/bootstrap-compiled/tree/xs-AB-subdivision.

@Jakobud This one is a branch.. https://github.com/donquixote/bootstrap/tree/xs-AB-subdivision

This is by far not the only approach posted in this thread, but I think it is the only one that is completely backwards compatible (unless someone can point out why it is not).

[antespi]

@grandfatha @Jakobud Here you have a Bootstrap branch example for minimal changes to add a breakpoint at 480px: https://github.com/Teachnova/bootstrap/tree/hs
I call this breakpoint HS (Horizontal Small Device)

Files changed (8 abr 2014 up-to-date):

• mixins/grid-framework.less : Add a new column to .make-grid-columns
• mixins/grid.less : Add .make-hs-columns (offset, push, pull)
• variables.less : Add @container-hs, @screen-hs-min, @screen-hs-max
• tables.less : .table-responsive until @screen-hs-max
• responsive-utilities.less : .visible-hs and hidden-hs (and so on)

I like Bootstrap framework for many reason but these are the most important for me:

• You can use it fast, the learning curve is low slope
• You can change its behavior very easly, because it is modular and follow DRY principles. You can check it with this example or @donquixote example.
• If you make any change you don't lose the "innovation train" because @mdo and @fat do not make crazy changes until next mayor version. This issue is an example of that.

It's a good idea to show how flexible is this framework in documentation

[matsaukeo]

For those times that I want the grid system to kick in at the "xs" breakpoint and not before it, I've started leaving the default system alone and just "undoing" the system below that point. So:

I add "col-xs-6" or whatever which means that by default we get columns from 0px upwards.
Then I add something like:

@media ((max-width:@screen-xs-min -1)){
    .selector [class^="col-"]{
        float:none;
        width:auto;
    }   
}

Seems like a fairly non-destructive stop gap while we wait for the extra break point and we can add it only when needed.

[DePalmo]

And I thought that I was the only one who is having problems with missing 480px breakpoint. Don't get me wrong, I do love Bootstrap 3 and I do admire the developers who created it (let's face it, they have made our lives much easier), but I don't understand what were they thinking when they selected breakpoints for BS3. Too much of people are still using smaller devices (below 768px wide) and (as do others) when I have to develop a properly responsive website, I always need to build my custom breakpoints for at least 640px and 480px, sometimes even for 320px (despite it very narrow and even I'm dropping support for it...).

I will give it a try to @andyl solution and shall see. The only thing I'm concerned is that his solution is for 480-767px and what will happen on 320px wide screens. Will see.

@mdo Keep up the good work, but if your time allows it, do please consider a update in near future that will add 480px breakpoint.

[Jakobud]

For anyone interested, I've made improvements to @andyl 's Mid-Small Layout (480px-767px) for SCSS (LESS version link added). I added in the visibility utilities for the Mid-Small layout .visible-ms and .hidden-ms as well as redefined the visibility classes for the Extra Small layout .visible-xs and .hidden-xs since the Extra Small breakpoint range changes with the addition of Mid-Small. I've also optimized the file to use Bootstrap's predefined grid generation and visibility class mixins.

SCSS: https://gist.github.com/Jakobud/c057577daddbde4dd709

LESS: https://gist.github.com/wdollar/135ec3c80faaf5a821b0

You can simply @import 'bootstrap-ms'; at the end of bootstrap.scss or bootstrap.less to use this. This allows you to fully utilize the Mid-Small layout grid and visibility classes without altering the original Bootstrap source (at the tiny expense of redefining a few xs classes).

[uroslates]

Here is how I would implemented this - with minimal effort (btw I'll guess you're using less):
0. In your variables.less file (or wherever you are defining your custom variables) add following:
@screen-xxs: 470px;

1. Create a new file called xxs-grid.less.
   2.The xxs-grid.less file's content is:
   @media (max-width: @screen-xxs) {
   .make-grid(xxs);
   }
2. In your main less file (eg. styles.less) include the newly added file:
   @import "./xxs-grid.less";
3. On your html element use newly created css class:
   class="col-lg-2 col-sm-4 col-md-3 col-xxs-12 col-xs-6"

[Jakobud]

@uroslates the problem has already been solved. Look at my gist.

[ilovett]

@Jakobud your solution is sass ... can you provide a less solution?

[wesdollar]

I forked what @Jakobud had contributed and fixed some sass to less issues. I briefly took it for a test drive, and it seemed to work as intended. I'll be doing some more robust testing today and tomorrow as part of the project I am currently working on. Will report back with any issues that are found if there are any. Thanks @Jakobud !

https://gist.github.com/wdollar/135ec3c80faaf5a821b0

[brgrz]

How are we supposed to use these since they are not actually LESS mixins? From within other LESS files I mean.

[wesdollar]

@brgrz Did you see where I fixed the LESS issues?

https://gist.github.com/wdollar/135ec3c80faaf5a821b0

Everything there is LESS ready. I'll keep an eye out for your reply in case you still have questions.

@ilovett See the link above if you still need the LESS solution.

[noctivityinc]

@Jakobud I tried the responsive helpers you created and they were causing troubles so I hacked BS responsive_utilities and added support for hidden-ms, seems to work:

https://gist.github.com/noctivityinc/1790c6b3e48befe91ac7

Also, if you want inline support for ALL responsive helpers just change _mixins.scss to:

  @mixin responsive-visibility($parent) {
      #{$parent} {
        display: block !important;
      }
      span#{$parent} {
        display: inline-block !important;
      }
      tr#{$parent} { display: table-row !important; }
      th#{$parent},
      td#{$parent} { display: table-cell !important; }
    }

[Jakobud]

Did you figure out the problem with mine? Feel free to fork the gist and post the fixes if you can figure it out. Thought I tested it thoroughly but I guess I missed something? What was the problem exactly? Do you have a jsfiddle or something you can show?

[noctivityinc]

There were a variety of issues, mostly dealing with visibility when it was not that screen size. Since you were setting a block to be visible only during that screen size, by forcing it to not be visible when dealing with a larger size we couldn’t use other classes. Basically, without diving into it too much, without resetting the hidden-ms class for the other screen sizes back to a default state it messed up the display.

Best,

Josh

Joshua Lippiner
.:t 704.323.5661
.:e [email protected] (mailto:[email protected])

On Wednesday, May 28, 2014 at 3:57 PM, Jake Wilson wrote:

Did you figure out the problem with mine? Feel free to fork the gist and post the fixes if you can figure it out. Thought I tested it thoroughly but I guess I missed something? What was the problem exactly? Do you have a jsfiddle or something you can show?

—
Reply to this email directly or view it on GitHub (#10203 (comment)).

[Jakobud]

Ah okay I will look into that. Thanks

[hnrch02]

GitHub's Gist feature also allows for comments. No need to do all the discussing related to that custom implementation on this issue tracker.

[noctivityinc]

True but I felt it relates to the bug/situation the same as some of the posts and anyone searching for this issue could benefit.

Joshua Lippiner
.:t 704.323.5661
.:e [email protected] (mailto:[email protected])

On Thursday, May 29, 2014 at 1:05 AM, Heinrich Fenkart wrote:

GitHub's Gist feature also allows for comments. No need to do all the discussing related to that custom implementation on this issue tracker.

—
Reply to this email directly or view it on GitHub (#10203 (comment)).