Add variable for max-width

[luispuerto]

This is an enhancement or feature.

Summary

I really don't know if you are interested in adding this to the theme. It comes to resolve a problem that is mainly there when you change the size of the browser in computers, o you have a small screen computer or an iPad. It felt that sometimes in smaller browser sizes some content was bigger, wider, than in bigger ones for no reason.

Create a new breakpoint in between "large" and "x-large" so the size changes are a little bit more fluid.

Tune-up how the right and left sidebars and the post/page content behaves. It feels more fluid now and usually when the size of the browser decreases the content decreases. Before at some breakpoints the content was bigger than in the wider breakpoint.

Create a $max-width variable, so know the content can be wider than the larger breakpoint. This variable is applied to page, search and masthead "__inner-wrap".

[MichaelJCaruso]

Having done a similar set of changes to my own fork of 'minimal-mistakes', perhaps this assignment should be written '$max-width: $x-large !default' so that overriding '$x-large' has the effect of also overriding the default value of 'max-width' as well.

[luispuerto]

I had something similar on my fork too, but then I realize that it's better that max-width has it's own entity, either similar as x-large if you want that way or some other larger if you want it.

[MichaelJCaruso]

We definitely need both $x-large and $max-width to be separate variables for exactly the reasons you state. My use, for example, is to leave $x-large at its current value and set $max-width to 100% (uses all the screen you paid for). My suggested change to your pull request aims to ensure that projects that currently override $x-large continue to behave as they always have. Currently, setting '$x-large' has the effect of changing both the breakpoint and the 'max-width' of a number of elements. As your pull request is written, existing projects that override '$x-large' will continue to override the breakpoint but will see the 'max-width' of elements that used to be set to their '$x-large' override now set to '1280px'.

[luispuerto]

@MichaelJCaruso this way you mean I guess.

[MichaelJCaruso]

Yes

[mmistakes]

It felt that sometimes in smaller browser sizes some content was bigger, wider, than in bigger ones for no reason.

Can you post some screenshot examples of these? I'd like to see how bad things can look before committing to adding another breakpoint.

[MichaelJCaruso]

Since Luis took the initiative to add the breakpoints, I expect he will have a better idea of the boundary conditions he fixed. I have, however, observed jumpy behavior as boundaries appear to be crossed. I'll see what I can put together. If you're interested in trying some of this for yourself, you can check out the non-trivial pages in https://michaeljcaruso.github.io/vision/ to see if anything jumps out at you. I'm not using Luis' fork, but I am using a fork that provides for separate override of $max-width (called $x-large-max-width in my world).

[luispuerto]

This is how the default theme behaves:

Which is a little bumpy. (Perhaps here is more noticeable).

And this is how behave with the PR in my web. Which is a little bit softer till it reacher the tablet size.

[mmistakes]

Ok, so the content isn't really breaking. This is more of "I'm the sort of person who goes to websites and resizes the browser to see how responsive they are" rather than a normal use case of reading the page as presented. 😉

Still not completely convinced this is a problem worth solving for by adding complexity of another breakpoint.

[luispuerto]

Ok, so the content isn't really breaking. This is more of "I'm the sort of person who goes to websites and resizes the browser to see how responsive they are" rather than a normal use case of reading the page as presented. 😉 ...

LOL!! 😂 Yeah!! it’s totally that!!

To be honest I told you upfront that I really didn’t know if this was going to be useful for you. For me the main issue here is the content should be always smaller / narrower as the browser window get smaller / narrower.

It’s true that one usually doesn’t change the browser window size, but I sometimes do... (to fit more than one window in the screen) and screens computers and resolutions really varies.

The aim of the pull is consistency in the way smaller screen always smaller content.

I understand that you want to keep the theme as simple as possible, though.

_{Sent with GitHawk}

[mmistakes]

Fair enough.
When flexbox and display: grid gain even more traction I can move away from floats and media queries for most of the layout. That will greatly improve how fluid the content is and remove all the hard stops based on a arbitrary breakpoint widths.

[MichaelJCaruso]

If I can chime in as an interested third party, while in the process of deploying a significant GitHub pages documentation site using minimal-mistakes, tuning the presentation of my own material led me to Luis' PR. While change dynamics are always going to be a matter of aesthetics and boundary behavior, one aspect of Luis' change that attracted my attention was its simple $max-width parameterization of screen width utilization. While we can always customize that in a fork (and I have), I'd like to upvote the inclusion of that feature in minimal-mistakes, especially given the way approaches to the correct solutions have changed in response to major rewrites of libraries like _sass. My two cents, for what it's worth (-: yes, I know, 2 cents :-)
Cheers

[mmistakes]

I see value in adding the $max-width Sass variable so you can better control container's width with max-width: $max-width;.

The other adjustments to fine tune the sidebar widths for large-wide were more of what I was directing my statements against.

@luispuerto If you want to retool the PR (or submit another one) with just the $max-width additions and leave out the new sidebar variables and large-wide breakpoints, I'd be happy to merge that in.

[luispuerto]

@mmistakes we can use this PR, I don't have a problem.

The modifications have been done 🙂

[luispuerto]

Perhaps for reference sake I'm going to drop here a link to the commit on my fork where I did the changes
luispuerto/luispuerto-net@da7744c

[mmistakes]

Looks good @luispuerto, thanks.