Gantry Grid System should stack at Mobile breakpoint; not the Tablet Breakpoint

[blizam]

I honestly always thought this was already the case. Even here:

http://docs.gantry.org/gantry5/advanced/responsive-content

It says: In mobile view, these blocks will stack on top of each other while in tablet or desktop view, these blocks will scale responsively. -- which isn't true; they stack at the Tablet breakpoint

It's this bit, in engines\nucleus\scss\nucleus\theme\breakpoints\ _flex.scss

body [class*="size-"] {
    @include breakpoint(mobile-only) {
        @include flex-grow(0);
        @include flex-basis(100%);
        max-width: 100%;
}

So it would seem, that when it's in 'Mobile Only' mode all the blocks will scale to 100% effectively stacking all your g-block content... makes sense to me...

but then in \engines\nucleus\scss\configuration\nucleus\ _breakpoints.scss

you have $mobile-only: "#{$media} and (max-width:#{$breakpoints-tablet-container - 0.062})" !default;

So "mobile-only" is using the Tablet value from Gantry's Breakpoint Settings.... why?? The majority of layouts have 2 or 3 columns. On tablets or small laptops you're almost always going to want to preserve 2 or 3 columns in a single row. By having "mobile-only" actually kick in at the Tablet value, it's not only confusing, but it makes the "mobile" value nearly worthless to the average user who isn't writing their own SCSS... "mobile" is where you'd naturally want to stack your site into a single column but since that's now happening at "Tablet" that means that 3 of 5 five values in the Breakpoint Settings (Mobile, Mobile Menu, and Tablet) will almost always have to bet set to the same value, again, making the Mobile Value in particular somewhat useless.

It would be much more useful to be able to use the Tablet setting for controlling font-sizes, margins, and paddings on small devices where you want to maintain your column layout but at present it's effectively the "stack everything for mobiles" breakpoint leaving only Desktop and Large Desktop as useful breakpoints to adjust content within rowed columns.

While I'd personally like to see the user controlled breakpoints increased to 6 or 7 options to allow for smaller device control (similar to spectre.css breakpoints) I feel that just making this small change would allow the existing user controlled breakpoints to be much more usable.

[ghost]

As far as I know the breakpoints are working just fine, I didn't noticed any issue. It might be a bit confusing at first, but breakpoints-tablet-container is the limit between mobile and tablet, it is used as upper limit for mobile and lower limit for tablet.

Currently in gantry you have:

• Small mobile (portrait view)
• Large mobile (landscape view)
• Tablet
• Desktop
• Large Desktop (in some themes I think)

Also, you can create as many breakpoints you need in your theme.

Right now you can control the grid only on desktop, and the columns will stack only on mobile (100% width). There's no way you choose another size for tablet. In my opinion the layout manager will need some improvements. I am not sure how. but...

I'll give you an example of how I use gantry.

I don't use the gantry grid that much and when I use it I add custom css to make it behave the way I need on different breakpoints.

When I create a particle, instead of adding 3 particle instances in a row (that will create 3 columns in layout manager) I use the collection field that allows me to create multiple items inside a particle. This way in layout manager I only use a particle instance and the column width is always 100%. For particle items I use custom css or my own grid. I don't use g-block, g-grid, etc, mainly because they are flex and I prefer css grid.

[ghost]

Small Mobile Range is between 0px and breakpoints-large-mobile-container; Large Mobile Range is between breakpoints-large-mobile-container and breakpoints-tablet-container; Mobile is grouping the above breakpoints and it is between 0px and breakpoints-tablet-container; Tablet Range is between breakpoints-tablet-container and breakpoints-desktop-container and so on...

[blizam]

As far as I know the breakpoints are working just fine, I didn't noticed any issue. It might be a bit confusing at first, but breakpoints-tablet-container is the limit between mobile and tablet, it is used as upper limit for mobile and lower limit for tablet.

I understand it's a range, but it kicks in at the value the user has in the Breakpoints Admin section on the Page Settings tab for Tablet; which is not only confusing but It makes the Mobile breakpoint effectively useless unless you're writing custom code that accesses the variables directly. I'd argue that in more situations than not you're simply going to be setting Mobile, Mobile Menu, and Tablet all to the same value, which is a waste of a usable field.

I can appreciate there are different ways to use the built in grid system but your alternative is effectively not using it at all. I'm posting here to improve the experience for people who are using it with normal gantry blocks and particles aligned in a row/grid. IMO it should be set to the small-mobile-range which uses the large-mobile-container value that's in the admin under Mobile for when size-xx block gets stacked at 100%.

[simmonsr]

I also think it's working just fine. As I mentioned in Slack,

(max-width:#{$breakpoints-tablet-container - 0.062}) means that it ends at last point of the tablet view minus a couple more rem

so in this case mobile-only is @media only all and (max-width: 47.938rem) { }

does that make sense?

as soon as tablet view is ending minus 0.062 then do this css

[ghost]

it kicks in at the value the user has in the Breakpoints Admin section on the Page Settings tab for Tablet

Think of it as a mobile first approach, start with a small canvas and resize, you will see that it doesn't kick in at Tablet value, but it ends there.

[blizam]

We're all saying the same thing... IMO it should be using the value in Mobile and not Tablet... what's the point of having the mobile value if it's breaking to a single column at the Tablet value... (I know there's other things you can do with that smaller mobile value but IMO it's main function should be to break the site into a single column)

[blizam]

Think of it the other way too... not only does it mean your Mobile value has little use when everything is already stacked at the value proceeding it (Tablet) but now you only 2 values to perform other constraints that are above that -- Desktop and Large Desktop... so now, if I want my site in a single column at 768px (or even smaller... 600, or 480)... I have to set 'Tablet' to that value and now I only have 2 other breakpoints above that... 1024 and 1280 maybe... or 960 and 1200... but now I have to create a custom size if I want to do anything special for large or 4k monitors... maybe I want to stop certain otherwise full-width containers from exceeding 1920 or something. I sould similarly argue that 1200, 1280, or 1440 is hardly a "large desktop" these days but in 90% of cases I think that's exactly where your large desktop value ends up getting set because you need at least 2 breakpoints between 768 and 1440 to perform basic things.

Ideally you'd have 5 or 6 values... but since there's only 4 values having the site stack at the "middle" of that range is very limiting for a variety of scenarios.

[blizam]

so in this case mobile-only is @media only all and (max-width: 47.938rem) { }

does that make sense?

as soon as tablet view is ending minus 0.062 then do this css

No, I don't think setting 'mobile-only' to the value in a field labeled 'Tablet' makes much sense. I completely understand the rationale of it being one end of a "mobile range" but I think it's confusing UX and limiting for the other reasons mentioned.

[ghost]

Actually Mobile is not really mobile, it is the breakpoint between Small Mobile (portrait) and Large Mobile (landscape). To keep consistency I think we should rename it to Large Mobile because that's what it really is.

The default breakpoints are: 480 768 960 1200

I think between 480 and 1200 we have enough breakpoints, and they were meant for this sizes. Now that we have bigger screens it doesn't mean that we should stretch or alter this breakpoints.

The breakpoints should stay as they are and if you need support for larger screen sizes new breakpoints can be added, like: 1400 1600 1920

Currently gantry don't have support for this sizes, but you can easily add them in your theme and they might be added to gantry core at a point.

Some gantry breakpoints are based on ranges, a breakpoint need 2 limits to function. Tablet label is where the tablet starts and the end of mobile is calculated automatically Tablet - 1px.

To have named ranges like Mobile, we should not calculate them automatically anymore and we will end with "almost duplicated" breakpoints, like

Mobile End: 767 Tabel Start: 768 Tablet End: 960

I get where you are confused but I kind of fail to explain :). I'll step aside for now as I start to repeat my self.

[blizam]

I do understand what you're saying and I understand why it is the way it is. I think it's confusing UX in general though and that it could easily confuse the average user.

I'm totally fine with the 4 default breakpoints as you laid them out as default sizes but perhaps they should instead be named 'Small Mobile','Large Mobile', 'Tablet' and 'Desktop'?

On most tablets, even in portrait mode, you can preserve a 2 or 3 column layout...

Based on those same defaults above I still think that this CSS:

        @include flex-grow(0);
        @include flex-basis(100%);
        max-width: 100%;

...should kick in at the smallest 480 breakpoint... that it should be tied to the 'Mobile' or 'Small Mobile' value. Given only 4 admin controlled breakpoints having the smallest valued one stack everything to a single column gives you more control over your site with the other 3 breakpoints, in my humble opinion.

Plus, you already have control of when the Mobile Menu kicks in with it's own value, so if you need your mobile menu to kick in before your site drops to 1 column that's already accounted for.

As-is, the 'Mobile' value has very little use and you're left with 1 less value for adjusting multi-column layouts responsively

[simmonsr]

You can use @include breakpoint(@large-mobile-range) {} and @include breakpoint(small-mobile-range) {} for your CSS if needed.

[simmonsr]

Sorry if that doesn't help this convo. Just thought I'd throw that out there in case you weren't aware.

[blizam]

I do know there's plenty of SCSS workarounds. My post here is in hopes of improving, in my opinion, the admin area experience... I still think having the site stack in 1 column based on the Mobile value in the Admin makes more sense, for a variety of reasons.

[simmonsr]

In case someone by interested in modifying the breakpoints, follow my path here:

So take wp-content/plugins/gantry5/engines/nucleus/scss/mixins/_breakpoints.scss

and add it so it shows as:

wp-content/themes/YOUR_THEME/custom/engine/scss/nucleus/mixins/_breakpoints.scss

[simmonsr]

If you are using a different CMS, please see Joomla and Grav tabs here:

http://docs.gantry.org/gantry5/advanced/file-overrides#gantry-directory-structure

[blizam]

You'll need to add this override as well:

/custom/engine/scss/nucleus/theme/breakpoints/_flex.scss

so that you can properly set your .g-container widths based on any modifications you made the the _breakpoints.scss file

For me, this is the route I took with this particular project... in the future I'll likely try to avoid these overrides; unless you override every single breakpoint value, or insert new ones, you can end up with a gap in ranges and then you have to chase down everywhere the variable(s) are in use if you're starting with a base theme/template of some kind.

I don't know if my arguement here is strong enough to warrant a change... I still think the "mobile" value in the g5 breakpoints admin is utterly useless the way it's setup now but I had a bigger headache trying to override everything than is likely worth it... in the future I'll probably just treat my Tablet value as the site's actual mobile breakpoint, set my mobile value to equal it, and create my own "real tablet" or "small dekstop" values in SCSS.

I hope the change can still be considered, but I'm good with this issue ticket being closed.