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

Grid breakpoint for 480px #10203

Closed
luaz opened this Issue Aug 27, 2013 · 129 comments

Comments

Projects
None yet
@luaz

luaz commented Aug 27, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 27, 2013

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

andyl commented Aug 27, 2013

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

@ggam

This comment has been minimized.

Show comment
Hide comment
@ggam

ggam Aug 27, 2013

Contributor

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

Contributor

ggam commented Aug 27, 2013

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

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 27, 2013

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

puzrin commented Aug 27, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 27, 2013

@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 commented Aug 27, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 28, 2013

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 commented Aug 28, 2013

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

This comment has been minimized.

Show comment
Hide comment
@luaz

luaz Aug 28, 2013

@andyl +1 for simple and safe

luaz commented Aug 28, 2013

@andyl +1 for simple and safe

@heldchen

This comment has been minimized.

Show comment
Hide comment

+1

@ggam

This comment has been minimized.

Show comment
Hide comment
@ggam

ggam Aug 29, 2013

Contributor

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

Contributor

ggam commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 29, 2013

@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

puzrin commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 29, 2013

@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 commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@ggam

ggam Aug 29, 2013

Contributor

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

Contributor

ggam commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@heldchen

heldchen Aug 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ggam

ggam Aug 29, 2013

Contributor

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

Contributor

ggam commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 29, 2013

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

andyl commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@heldchen

heldchen Aug 29, 2013

@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 3.1 has other BC-breaking stuff planned, so what's not really a good reason not to think about it, is it?

@ggam

This comment has been minimized.

Show comment
Hide comment
@ggam

ggam Aug 29, 2013

Contributor

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

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

Contributor

ggam commented Aug 29, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@heldchen

heldchen Aug 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Aug 29, 2013

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

andyl commented Aug 29, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@igormalyk

igormalyk Sep 3, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@igormalyk

igormalyk Sep 3, 2013

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 ?

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

This comment has been minimized.

Show comment
Hide comment
@jkins

jkins Sep 4, 2013

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

jkins commented Sep 4, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Sep 4, 2013

Member

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.

Member

mdo commented Sep 4, 2013

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 mdo closed this Sep 4, 2013

@andyl

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 4, 2013

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

andyl commented Sep 4, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@jkins

jkins Sep 4, 2013

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

jkins commented Sep 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@greggian

greggian Sep 4, 2013

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

greggian commented Sep 4, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Sep 5, 2013

Member

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

Member

mdo commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 5, 2013

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

andyl commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@luaz

luaz Sep 5, 2013

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.

luaz commented Sep 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Sep 5, 2013

Member

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

Member

mdo commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 5, 2013

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

andyl commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Sep 5, 2013

Member

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.

Member

mdo commented Sep 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 5, 2013

@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 commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 5, 2013

@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 commented Sep 5, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@michaelvandonselaar

michaelvandonselaar Sep 5, 2013

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

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

@andyl

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 5, 2013

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

andyl commented Sep 5, 2013

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

@luaz

This comment has been minimized.

Show comment
Hide comment
@luaz

luaz Sep 6, 2013

@andyl thanks. Will test this out.

luaz commented Sep 6, 2013

@andyl thanks. Will test this out.

@zzseba78

This comment has been minimized.

Show comment
Hide comment
@zzseba78

zzseba78 Sep 27, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@andyl

andyl Sep 27, 2013

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

andyl commented Sep 27, 2013

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

@donquixote

This comment has been minimized.

Show comment
Hide comment
@donquixote

donquixote Mar 2, 2014

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.

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.

@donquixote

This comment has been minimized.

Show comment
Hide comment
@donquixote

donquixote Mar 2, 2014

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

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

@donquixote

This comment has been minimized.

Show comment
Hide comment
@donquixote

donquixote Mar 2, 2014

I am renaming the ranges to xs0 and xs1 instead of xs-A and xs-B.
@mdo I realized that the PR was closed, but I can imagine that others might be interested.

I am renaming the ranges to xs0 and xs1 instead of xs-A and xs-B.
@mdo I realized that the PR was closed, but I can imagine that others might be interested.

@donquixote

This comment has been minimized.

Show comment
Hide comment
@donquixote

donquixote Mar 5, 2014

@luaz, @andyl, @carasmo, everyone who is interested:
The additional break point in https://github.com/donquixote/bootstrap/tree/xs-AB-subdivision works great and does not interfere at all with existing behaviors. We could work on that as a "fork" (while still pulling changes from upstream), until everyone switches to Bootstrap 4.

The question is whether 480 is enough, or if we want additional break points / intervals. The subdivision concept allows for a lot more than just one new break point. We could have xs0, xs1, xs2, xs3, xs00, xs01, xs02, md0, md1, md2, md00, md01, etc.

We could discuss this in the issue queue over at donquixote/bootstrap, to spare the inbox of the bootstrap maintainers.

@luaz, @andyl, @carasmo, everyone who is interested:
The additional break point in https://github.com/donquixote/bootstrap/tree/xs-AB-subdivision works great and does not interfere at all with existing behaviors. We could work on that as a "fork" (while still pulling changes from upstream), until everyone switches to Bootstrap 4.

The question is whether 480 is enough, or if we want additional break points / intervals. The subdivision concept allows for a lot more than just one new break point. We could have xs0, xs1, xs2, xs3, xs00, xs01, xs02, md0, md1, md2, md00, md01, etc.

We could discuss this in the issue queue over at donquixote/bootstrap, to spare the inbox of the bootstrap maintainers.

@youngrok

This comment has been minimized.

Show comment
Hide comment
@youngrok

youngrok Mar 10, 2014

👍 IMHO, tn(<=480px) is much more important than lg (>1200px). In most cases md is enough. Who design website for over 1200px? It's useless. If the number of cases matters, just downsize all. xs<=480, sm<=768, md<=992, lg>=992. Or just add tn<=480 please.

👍 IMHO, tn(<=480px) is much more important than lg (>1200px). In most cases md is enough. Who design website for over 1200px? It's useless. If the number of cases matters, just downsize all. xs<=480, sm<=768, md<=992, lg>=992. Or just add tn<=480 please.

@matsaukeo

This comment has been minimized.

Show comment
Hide comment
@matsaukeo

matsaukeo Mar 11, 2014

Just to add to this - I've used bootstrap 3 on about 5 projects now and each time I've had to update the LESS files to add this extra breakpoint. Each time it's caused headaches as passing things on to developers or even looking back on it gets confusing. Also the responsive visibility classes have bitten me in the ass a few times!!

It sounds as though @mdo agrees that we need the extra break point and I can understand why he's being careful about adding it. I hope this gets added as standard sooner rather than later.

Big thanks to @mdo!

Just to add to this - I've used bootstrap 3 on about 5 projects now and each time I've had to update the LESS files to add this extra breakpoint. Each time it's caused headaches as passing things on to developers or even looking back on it gets confusing. Also the responsive visibility classes have bitten me in the ass a few times!!

It sounds as though @mdo agrees that we need the extra break point and I can understand why he's being careful about adding it. I hope this gets added as standard sooner rather than later.

Big thanks to @mdo!

@grandfatha

This comment has been minimized.

Show comment
Hide comment
@grandfatha

grandfatha Mar 25, 2014

Amazing thread; I too need the hack for the additional breakpoint right now.

Writing websites was fun before we had to support all those devices in a single html file.

Amazing thread; I too need the hack for the additional breakpoint right now.

Writing websites was fun before we had to support all those devices in a single html file.

@baxang

This comment has been minimized.

Show comment
Hide comment
@baxang

baxang Mar 26, 2014

After reading this long thread, I decided to add a breakpoint myself and wrote a quick-and-dirty patch that adds a 'tn(tiby)' which covers 0..479px and shrink xs's coverage to 480..767px.

Since I'm using bootstrap-sass for my rails project, my patch is supposed to be included after vanila bootstrap.scss. What it does is that it adds some mixins for the new breakpoint and re-declare grids. In addition it also takes care of responsive-utilities such as .visible-tn.

  • I didn't consider compatibility issues as I just migrated from TB 2.3.
  • I didn't want to change a line of TB core so I copied code from the original and modified accordingly. My code is not well tested, but is working well for me.

The code is https://gist.github.com/baxang/9775806 and any feedback would be appreciated.

baxang commented Mar 26, 2014

After reading this long thread, I decided to add a breakpoint myself and wrote a quick-and-dirty patch that adds a 'tn(tiby)' which covers 0..479px and shrink xs's coverage to 480..767px.

Since I'm using bootstrap-sass for my rails project, my patch is supposed to be included after vanila bootstrap.scss. What it does is that it adds some mixins for the new breakpoint and re-declare grids. In addition it also takes care of responsive-utilities such as .visible-tn.

  • I didn't consider compatibility issues as I just migrated from TB 2.3.
  • I didn't want to change a line of TB core so I copied code from the original and modified accordingly. My code is not well tested, but is working well for me.

The code is https://gist.github.com/baxang/9775806 and any feedback would be appreciated.

@aakilfernandes

This comment has been minimized.

Show comment
Hide comment
@aakilfernandes

aakilfernandes Apr 2, 2014

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

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

@aakilfernandes

This comment has been minimized.

Show comment
Hide comment
@aakilfernandes

aakilfernandes Apr 2, 2014

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

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

@Jakobud

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud Apr 7, 2014

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.

Jakobud commented Apr 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Outdoorsman

Outdoorsman Apr 7, 2014

I totally agree!

I totally agree!

@Jakobud

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud Apr 7, 2014

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

Jakobud commented Apr 7, 2014

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

@cvrebert

This comment has been minimized.

Show comment
Hide comment
@cvrebert

cvrebert Apr 7, 2014

Member

@Jakobud Nope. Read the prior comments for why.

Member

cvrebert commented Apr 7, 2014

@Jakobud Nope. Read the prior comments for why.

@grandfatha

This comment has been minimized.

Show comment
Hide comment
@grandfatha

grandfatha Apr 7, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud Apr 8, 2014

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;

Jakobud commented Apr 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@donquixote

donquixote Apr 8, 2014

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

@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

This comment has been minimized.

Show comment
Hide comment
@antespi

antespi Apr 8, 2014

@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

antespi commented Apr 8, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@matsaukeo

matsaukeo Apr 16, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@DePalmo

DePalmo Apr 26, 2014

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.

DePalmo commented Apr 26, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud May 5, 2014

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

Jakobud commented May 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@uroslates

uroslates May 6, 2014

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"

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud May 6, 2014

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

Jakobud commented May 6, 2014

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

@ilovett

This comment has been minimized.

Show comment
Hide comment
@ilovett

ilovett May 9, 2014

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

ilovett commented May 9, 2014

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

@wesdollar

This comment has been minimized.

Show comment
Hide comment
@wesdollar

wesdollar May 15, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@brgrz

brgrz May 21, 2014

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

brgrz commented May 21, 2014

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

@wesdollar

This comment has been minimized.

Show comment
Hide comment
@wesdollar

wesdollar May 21, 2014

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

@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

This comment has been minimized.

Show comment
Hide comment
@noctivityinc

noctivityinc May 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud May 28, 2014

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?

Jakobud commented May 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@noctivityinc

noctivityinc May 28, 2014

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 jlippiner@noctivity.com (mailto:jlippiner@noctivity.com)

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

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 jlippiner@noctivity.com (mailto:jlippiner@noctivity.com)

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud May 28, 2014

Ah okay I will look into that. Thanks

Jakobud commented May 28, 2014

Ah okay I will look into that. Thanks

@hnrch02

This comment has been minimized.

Show comment
Hide comment
@hnrch02

hnrch02 May 29, 2014

Member

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

Member

hnrch02 commented May 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@noctivityinc

noctivityinc May 29, 2014

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 jlippiner@noctivity.com (mailto:jlippiner@noctivity.com)

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

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 jlippiner@noctivity.com (mailto:jlippiner@noctivity.com)

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

@twbs twbs locked and limited conversation to collaborators Jun 9, 2014

@twbs twbs unlocked this conversation Jun 9, 2014

@twbs twbs locked and limited conversation to collaborators Jun 9, 2014

sergio91pt added a commit to sergio91pt/bootstrap that referenced this issue Jan 19, 2015

Add grid breakpoint for 480px
This is the col-ms purposal in twbs/bootstrap#10203 for v3.3.1

slackero added a commit to slackero/bootstrap that referenced this issue Apr 8, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.