SCSS Breakpoint Variables

[Brockenstein]

I was asked by the Louisville team to add this to standards.

Currently we are generally using
$mid-small, $end-small, $max-width

Which I find I rarely need more than these 3 but the questions comes into if you need more variables what should they be called? I know I have added $smallest and $mid-max before but really we should have a naming convention.

We have see several other options such as, break6 for min width of 600px then break8 for min width of 800px and so on. Also we have seen, Mobile, Tablet, Desktop. or Smallest, Small, Middle, Large, Largest. We have also seen phone-s, phone, tablet-s, tablet, tablet-l, desk.

After reading some articles and so many different developers commenting on their way of doing it. I am leaning towards the thought of why make it confusing by obscuring? Ultimately If you are going to obscure your breakpoint sizes make sure that it is something people can understand like wrist, palm, lap, desk, wall, mall you obviously know that palm is smaller than desk.

Some confusing obscuring examples are Homer, Marge, Bart, Lisa, Maggie or the current favorite of some of our developers. Death star, Luke, Leia, etc. While doing these may be fun, let me tell you, they are hell to work with when you aren't the developer who originally wrote them. Several of the developers have complained about not understanding why one variable is larger than the other.

For this reason we should decide on a naming convention. I will create another issue for the mixin.

[sbkates]

I usually use ones specific to the meaning. End-tablet, end-iphone,
mid-small, largest-screens. I figure it's clear enough what it means when
taken in context of the default ones (end-small comes after mid-small, of
course, End-tablet would logically come after end-small.) I never use 'fun'
names since it's even confusing to me.

[jkmahoney]

I agree that we should have an agreed upon naming convention for variables. A developer shouldn't have to be taught what your variable naming convention means or is before they begin working with your code. The naming convention should be something that any developer can pick up and run with without having to guess and the "reasons for and why" a naming convention was used. Making our variable naming convention more uniform for everyone to catch on to, understand, work with and update in the future is very important.

[stephendelancey]

I use the break6 - break12 normally
in my mixin I have a break for 600, 800, 1000, 1200. I use 800 and 1000 the most but I use the 600 and 1200 enough to include them. the reason I used these because I couldn't remember the default variables always.

there has also been sites that I have found with the starwars variables where I have just done my own sass because it would have taken to long to adapt those variables to what I was doing.

so in conclusion I agree and the variables should be something you can get with just glance like: break6, break8, bp6, bp10, small, smallest. having a number in the name helps me a lot as well.

[Brockenstein]

@stephendelancey I like this idea, we could have a mixin where your variables are number based. So say you need a variable that is 768 you would do @include bp(7) { } then a variable of 1024 would be @include bp(10) { } and so forth. That isn't that obscure but it allows you to still have variables you can easily change.

[sbkates]

What if we just used break-xs, break-s, break-m, break-l, break-xl,
break-xxl? Or name them after devices, as is a standard norm elsewhere.
On May 23, 2016 5:24 PM, "Josh Mahoney" notifications@github.com wrote:

I agree that we should have an agreed upon naming convention for
variables. A developer shouldn't have to be taught what your variable
naming convention means or is before they begin working with your code. The
naming convention should be something that any developer can pick up and
run with without having to guess and the "reasons for and why" a naming
convention was used. Making our variable naming convention more uniform for
everyone to catch on to, understand, work with and update in the future is
very important.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#24 (comment)

[stephendelancey]

@Brockenstein @sylviakates
either one of those is fine though if we wanted a standard, Sylvia's would probably be better. I use the numbers because except for rare moments I use all round numbers for my break points because it fits the way I build stuff out a bit better. if I ever use a number that isn't round it is usually for something with weird spacing that has a super specific point where in needs to break like banner text.
At that point I would just write a regular media query because I am only using it once probably.

[Mattferguson0422]

I agree whole heartedly that any variable should not have obscure naming. This is poor practice and unprofessional. Our goal is to write clean code that anyone can go behind and maintain. Variables should be clearly defined. We don't all have to use $end-small for the last mobile break point however the variable should clearly define it's value. $end-mobile, $start-desktop, whatever. My vote is that our standards reflect the same sort of naming as we use for assets.

[actaylor87]

I also agree with not using obscure variable names. On a maintenance perspective, it becomes more troublesome. The more standard we make them helps us out a bunch. Since there are so many sites to maintain keeping a standard helps us not to have to hunt down variable names to find out which break point is which every time we need to make a change. Like I currently know that around the 800px mark, that $end-small is most likely the variable used so I can just use that rather than always having to check. I always do a quick scan of the break point variables before I make updates but the standard ones are more descriptive and easier to remember while working in the code.

[lmahoney1218]

I agree that all of our variables (not just breakpoints) should be named descriptively - just like we currently do for assets per the standards guide. This will make editing code after the initial build easy for any dev to understand. Anything we can do to make our code cleaner and help readability for any future dev maintaining it is a good idea.

[rehamm01]

I agree with the rest of Pro Naming-Convention comments. I think it'll be easier if we're all on the same page with how we name things. The number-based naming (break-8, break-9, break-10 etc.) seems like it would be easier to remember as I'm typing css, however the description-based naming (small, medium large or end-mobile, start-desktop) is more descriptive. So either naming method makes sense to me!

[michaelspellacy]

In my defense of unprofessional use of Star Wars naming conventions, the idea here was to abstract the name enough so that is not bound to any one particular size, as sizes are privy to change at the drop of hat. If we can come up with and agree upon naming conventions that do not target size or device, etc, I am all for it. But we would be doing same thing I did by using (fun) names, except just using standardized names. :-)

[michaelspellacy]

Small, medium, large, etc, while descriptive, could be a problem. With so many devices on the market , what range of widths truly define these names? What if small suddenly needs to be a higher number? In the same way you should not be using presentational names in your CSS, the same can also be said for sizes, which could also be seen as presentational. Like the idea above about something a little more generic, like break-1, break-2, etc.

[michaelspellacy]

Yes, @landerson1218, what we are creating is a common language for all of us to speak.

[Brockenstein]

@michaelspellacy I agree that our sizes should be flexible. I am fine with not naming it by device. But I am not understanding the issue with small medium large, or even adding in when needed mid-small. mid-large? It is unlikely that once you have started a project that you will need to be changing these variables. I understand that breakpoint sizes may fluctuate from site to site, but after you have set them in initial development how often will they change? We aren't requiring certain sizes per variable, just a naming convention that is easy to understand and add to and remember when working with the code.

From my experience I have never needed more than 5 breakpoints variables, ideally I try to only do 3 breakpoint variables. There might be one off cases where you need to target on one specific item with a breakpoint that needs to be fixed at a certain size but not every breakpoint has to be a variable.

I get your point that mobile isn't and won't always be 800px or less but so far current mobile devices, even devices with retina and high resolutions report back to the browser a lower resolution than what the screen is capable of displaying. For example, the iPad Air reports a screen size of 768x1024, like other iPads, even though its actual pixel count is 1536x2048. The Galaxy S4 reports 1/3 its actual pixel count. This allows us to continue to use min-width at in our breakpoints. now if you need to target a certain device then you could use min-device-width with the correct pixel ratio but we aren't talking about that. We are talking about making a naming convention that covers any size we need for the current project. And while I understand you are concerned about naming the variable tablet and that not variable not matching that device resolution but due to the fact that current devices report a lower number than actual screen resolution I don't think currently there is a large risk for this concern. If it does change, and all the sudden all mobile cell phones are now 640px instead of 320px and we have to change our code for that, then we can change our standards for that but I am betting by that point there will be a whole new set of media queries we will have to use so TMPs site will probably be redone to use those anyway, so the obscured variables probably won't help at that point because all the media queries will have to be built.

I am not saying that a certain level of obscuring is not needed, because i do feel that the values of our variables should be able to be changed per site. Can you explain though the situations you have been in where sizes changed at the drop of a hat like you said where the super obscure variables you use helped? The only time I can think where all the sudden a desktop variable was no longer the needed variable was when I was using a variable of max width as my "desktop" size and they wanted the site to be wider after I had built it. I am not seeing how using your obscure variables would have helped me, I think I should have just not used the same variable for max width in my breakpoint. In fact if i had instead used small medium large as my breakpoint variables, left my max-width variable as max width and had the large variable the same size as the max-width variable, I could have added a new variable of extra-large and changed my max-width value to match that size. And then if I needed to fix any layout issues then I could have used the extra-large variable. But really, my css should have been good enough that increasing the max width shouldn't have required more variables anyway.

You say that you want abstract names so that it is not bound to any one particular size but after you have used your Star Wars variables for so long, does your mind not start to say Luke is for mobile and deathstar is for desktop? So in the end isn't your obscuring doing the same thing as labeling them as mobile or tablet? Also what do you do when you need to add in a variable between luke and deathstar, if you add yoda into the middle of those two how do you remember that yoda is in between the other sizes?

[jkmahoney]

I am not sure why there would be a problem with using a common variable
naming convention like (small, medium, large, max), if you had to throw
additional variables into this for in-between sizes it could be easily
accommodated by adding in (small-medium, medium-large, etc.), these all
appear to be obscure to me. They do not tell you what device or platform
variable break point would be used for, but any developer could come along
after you have built your site and your code and easily read and understand
that small would be your smallest break point, medium would be a medium
break point, large would be a larger one, etc. You could change the numbers
on those variables without having to switch the variables around in your
code and without conflicting with anything else. It seems so simple to me.

I did have to work with the Star Wars variables with the TMP site and they
were not easily understandable to me. Throughout the project I had to keep
going back and referencing the variable names and sizes because they didn't
make sense to me. The order we were calling them in and the size each
represented was clear from someone who doesn't know Star Wars that well or
the thought behind the convention. I also had problems with other variable
names on the TMP site when we used peoples names for gradients and such,
this threw me off because again I had to keep going back and referencing
them in order to know what name went with what gradient color.

I think that sometimes trying to be to obscure in our variable naming
convention can cause confusion to a new developer to a project. The whole
purpose of having a set of standards is to make it more simple and easier
to understand for any new developer on a project to come along and hit the
ground running on making updates, maintaining, or making additions to the
existing code.

I am not trying to hate on Star Wars with any of this, i just don't
understand the naming convention or how it makes the code cleaner, easier
to read, easier to understand and easier to maintain through time. If we
could get an explanation of why using something like (Small, Medium, Large)
is not a good practice or good standard to hold to or why they are not
obscure enough and why using something like character names from a
show/movie or terms related to a sport or something would be better and how
they would make more sense I am open to listening.

When thinking about a variable naming convention I think about being a new
developer to the company or to a project and being asked to add several new
sections or elements to a site or page and make it all responsive. I think
about what names for different break points would make the most sense and
be the simplest to understand and start working with without extra work
time having to be put in to study variable names and the sizes of them in
order to start working.

On Wed, May 25, 2016 at 7:27 PM, Brock Barnett notifications@github.com
wrote:

@michaelspellacy https://github.com/michaelspellacy I agree that our
sizes should be flexible. I am fine with not naming it by device. But I am
not understanding the issue with small medium large, or even adding in when
needed mid-small. mid-large? It is unlikely that once you have started a
project that you will need to be changing these variables. I understand
that breakpoint sizes may fluctuate from site to site, but after you have
set them in initial development how often will they change? We aren't
requiring certain sizes per variable, just a naming convention that is easy
to understand and add to and remember when working with the code.

From my experience I have never needed more than 5 breakpoints variables,
ideally I try to only do 3 breakpoint variables. There might be one off
cases where you need to target on one specific item with a breakpoint that
needs to be fixed at a certain size but not every breakpoint has to be a
variable.

I get your point that mobile isn't and won't always be 800px or less but
so far current mobile devices, even devices with retina and high
resolutions report back to the browser a lower resolution than what the
screen is capable of displaying. For example, the iPad Air reports a screen
size of 768x1024, like other iPads, even though its actual pixel count is
1536x2048. The Galaxy S4 reports 1/3 its actual pixel count. This allows us
to continue to use min-width at in our breakpoints. now if you need to
target a certain device then you could use min-device-width with the
correct pixel ratio but we aren't talking about that. We are talking about
making a naming convention that covers any size we need for the current
project. And while I understand you are concerned about naming the variable
tablet and that not variable not matching that device resolution but due to
the fact that current devices report a lower number than actual screen
resolution I don't think currently there is a lar ge risk for this concern.
If it does change, and all the sudden all mobile cell phones are now 640px
instead of 320px and we have to change our code for that, then we can
change our standards for that but I am betting by that point there will be
a whole new set of media queries we will have to use so TMPs site will
probably be redone to use those anyway, so the obscured variables probably
won't help at that point because all the media queries will have to be
built.

I am not saying that a certain level of obscuring is not needed, because i
do feel that the values of our variables should be able to be changed per
site. Can you explain though the situations you have been in where sizes
changed at the drop of a hat like you said where the super obscure
variables you use helped? The only time I can think where all the sudden a
desktop variable was no longer the needed variable was when I was using a
variable of max width as my "desktop" size and they wanted the site to be
wider after I had built it. I am not seeing how using your obscure
variables would have helped me, I think I should have just not used the
same variable for max width in my breakpoint. In fact if i had instead used
small medium large as my breakpoint variables, left my max-width variable
as max width and had the large variable the same size as the max-width
variable, I could have added a new variable of extra-large and changed my
max-width value to match that size. And then if I needed to fix any layout
issues then I could have used the extra-large variable. But really, my css
should have been good enough that increasing the max width shouldn't have
required more variables anyway.

You say that you want abstract names so that it is not bound to any one
particular size but after you have used your Star Wars variables for so
long, does your mind not start to say Luke is for mobile and deathstar is
for desktop? So in the end isn't your obscuring doing the same thing as
labeling them as mobile or tablet? Also what do you do when you need to add
in a variable between luke and deathstar, if you add yoda into the middle
of those two how do you remember that yoda is in between the other sizes?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#24 (comment)

[cb4430]

I think what we should be focused on is the fact that we are only talking about setting a standard for the variables and not the pixel width that is set to them... They need to be descriptive, not generic, so that at a glance a developer that comes behind to update or fix issues they are able to quickly identify breakpoints without having to scroll up to the top of the SASS file every time they need to add a breakpoint.

I believe we should use variables with names as x-small, small, medium, large, x-large and max-width. These are quick and simple and vague enough as to not be tied to a specific device like mobile or desktop, and the numbers do not need to be the same from one TB to the next. One TB may have a 400px x-small, and another will have a 550px x-small... The breakpoints variable amounts do not have to be the same, just the variable names need to be consistent from one TB to the next.

We all need to keep in mind that once we finish building these TB that we have an awesome team of PSS devs that work day in and day out to continue to support the TBs we build. If they can not read our code, or have to make major changes to the code to fix an issue that arises down the road, that just takes more of their time away from other tickets and issues.

[scampbell44]

My vote goes toward -- x-small, small, medium, large, x-large and max-width as well. Everyone recognizes these and they are not device specific.

I have to agree with the others on obscure names. Since there is always the potential someone else may be maintaining and/or extending upon sites we build, I think the simpler the better for standard break-point variable names. Not being a Stars Wars fan, I would also have to constantly be referencing the actual sizes if variable names were being drawn from this movie and I was working on a maintenance ticket for that site. Nothing against that movie, it's just not within my preferred genre of films.

[argusprescott]

I am in full agreement with the previous comments. Why make it more complicated? x-small, small, medium, large, x-large conveys the breakpoints at a level we can all understand easily and keeps it consistent.

[michaelspellacy]

Guys, take it easy. LOL! I am all for what the majority wants here, as always, but try to understand why I did what I did before passing judgement (or calling such things bad practice or unprofessional). There are a dozen and half ways to do things in this business, but this is why we standardize. :-) Heck, even Chris Coyier, a fellow we all admire, has recommended abstracting breakpoint names. See https://css-tricks.com/naming-media-queries.

Process played a role on a few of sites I have done in the past, especially our corporate site, in that I started before design was complete (as I tend to do to get a leg up when I can), so abstracting the names in this manner actually made development MUCH EASIER because the designs, especially on our corporate site, were a MOVING TARGET. Having something be "medium", only to have it change by a certain amount of pixels and bleed over into "large" territory, would mean having to change those breakpoints throughout my code from medium to large, etc. Not something I was keen on doing (especially if you have seen the corporate sites Sass) whenever a change in the design occurred. When you have a dozen breakpoints or more, small, medium, large, x-large, xx-large, xxx-small, etc. can be equally confusing.

@jkmahoney While I can't speak for all developers, I do understand how my method could be confusing. My apologies if it was troublesome. It was an effort to save time and lessen confusion. What I did was print out the breakpoints and hang it next to my monitor for a quick ref throughout dev. After a couple of passes, it became very easy to commit them memory.

I agree that having something easier to digest, especially for maintenance, is needed, so if the majority feel that using size is best, then that is fine. Will even change what I did on corporate to reflect the new standard we come up with.

@Brockenstein , please create a draft and post it here for our review. Thanks!

[Brockenstein]

@michaelspellacy it is funny that you mention Chris Coyier because his article is actually one I read and I read a large portion of the comments before I even started this issue. Chris Coyier's method was still easily identifiable as to which variable was large than another one. And it sounds like based off of the comments here our team wants to do something similar with our breakpoint variables that is make them obscure yet also easily identifiable as being larger than the other.

When I personally do breakpoints I think in min-width. So I am always thinking end of mobile do this end of tablet do this and once you have hit max width do this. That is why I have always been happy with end-small, mid-small and max-width. So please understand this will be difficult for me to adjust to as well but if it makes it easier for everyone then great.

Looks like the most comment mentioned on is
xsmall, small, medium, large, xlarge

What do you guys think about if we need to add more after we have set these?
Is mid-small-medium and mid-medium-large okay if I wanted to add a variable in-between small and medium or in-between medium and large?

What about if I need to add a smaller variable or a large variable?
xxsmall and xxlarge work for you guys?

I think we should agree to NOT use the max-width variable in the breakpoint. As this variable is normally meant for the content wrapper and you may need to change your breakpoint or content wrapper size separate from one another.

Also we have to ask the question, once we set this standard will it be required to update the default variables every single project or is it only an requirement if you are doing additional variables or until it is changed in the default code?

Also we saw a couple of other breakpoints variable solutions I want to hear the teams reasons why we should go with them. I am going to mention another that was mentioned and actually why i don't think we should use it.

I personally thought when using:

$device_widths: (100px, 200px, 300px, 400px, 500px, 600px, 700px, 800px, 900px, 1000px, 1100px, 1200px, 1300px, 1400px);

@mixin bp($i){
    @media only screen and (min-width: (nth($device_widths, $i))) {
        @content;
    }
}

it could be used like $break-3 or $bp3 is 300 but if we go this route that brekpoint can only be between 300 and 399 pixels

Or if we do this is way:

$device_widths: (480px, 600px, 800px, 900px, 1200px);

@mixin bp($i){
    @media only screen and (min-width: (nth($device_widths, $i))) {
        @content;
    }
}

We could do $bp2 is 600px $bp5 is 1200px but if you were in the middle of a project you couldn't easily add one as in-between. If I needed a variable for 1024px You could add another one but then that would mean $bp6would be smaller than $bp5 which is exactly the confusion we want to avoid.

So please everyone tell me if you like xsmall, small, medium, large, xlarge and are cool with say mid-"first variable"-"second-variable" for your in betweens such as mid-large-xlarge and if you need to add more doing xxsmall or xxlarge.

meaning default wise we would see
$xsmall, $small, $medium, $large, $xlarge

possibly seeing this often
$xsmall, $small, $mid-small-medium, $medium, $mid-medium-large, $large xlarge

This would be mean you could potentially have :
$xxsmall, $mid-xxsmall-xsmall, $xsmall, $mid-xsmall-small, $small, $mid-small-medium, $medium, $mid-medium-large, $large, $mid-large-xlarge, $xlarge, $mid-xlarge-xxlarge, $xxlarge

I have to be honest if you are using 13 breakpoints I have to question what you are doing.

[jkmahoney]

I am fine with the naming convention you are proposing, Brock. We could
also go with something as little simpler and easier to remember like $xs,
$s, $sm, $m, $ml, $l, $xl, $xxl (shirt sizes, something we can all remember
and deal with on a regular basis).

I also concur with you on using an absurd amount of breakpoints. I normally
use 3 breakpoints in my builds. I have on occasion when faced with a
complicated element had to use 4 or 5 breakpoints, but that is a rare
occurrence with the advancement our creative has made and what we have the
ability to do with HTML and CSS now.
If you are using 5 or more breakpoints on a regular basis then either the
designs are way too complicated in which case we need to have a talk with
creative and push back on designs, or you might not be using the power of
CSS to it's fullest.

On Fri, May 27, 2016 at 8:59 PM, Brock Barnett notifications@github.com
wrote:

@michaelspellacy https://github.com/michaelspellacy it is funny that
you mention Chris Coyier because his article is actually one I read and I
read a large portion of the comments before I even started this issue.
Chris Coyier's method was still easily identifiable as to which variable
was large than another one. And it sounds like based off of the comments
here our team wants to do something similar with our breakpoint variables
that is make them obscure yet also easily identifiable as being larger than
the other.

When I personally do breakpoints I think in min-width. So I am always
thinking end of mobile do this end of tablet do this and once you have hit
max width do this. That is why I have always been happy with end-small,
mid-small and max-width. So please understand this will be difficult for me
to adjust to as well but if it makes it easier for everyone then great.

Looks like the most comment mentioned on is
xsmall, small, medium, large, xlarge

What do you guys think about if we need to add more after we have set
these?
Is mid-small-medium and mid-medium-large okay if I wanted to add a
variable in-between small and medium or in-between medium and large?

What about if I need to add a smaller variable or a large variable?
xxsmall and xxlarge work for you guys?

I think we should agree to NOT use the max-width variable in the
breakpoint. As this variable is normally meant for the content wrapper and
you may need to change your breakpoint or content wrapper size separate
from one another.

Also we have to ask the question, once we set this standard will it be
required to update the default variables every single project or is it only
an requirement if you are doing additional variables or until it is changed
in the default code?

Also we saw a couple of other breakpoints variable solutions I want to
hear the teams reasons why we should go with them. I am going to mention
another that was mentioned and actually why i don't think we should use it.

I personally thought when using:

$device_widths: (100px, 200px, 300px, 400px, 500px, 600px, 700px, 800px, 900px, 1000px, 1100px, 1200px, 1300px, 1400px);

@mixin bp($i){
@media only screen and (min-width: (nth($device_widths, $i))) {
@content;
}
}

it could be used like $break-3 or $bp3 is 300 but if we go this route
that brekpoint can only be between 300 and 399 pixels

Or if we do this is way:

$device_widths: (480px, 600px, 800px, 900px, 1200px);

@mixin bp($i){
@media only screen and (min-width: (nth($device_widths, $i))) {
@content;
}
}

We could do $bp2 is 600px $bp5 is 1200px but if you were in the middle of
a project you couldn't easily add one as in-between. If I needed a variable
for 1024px You could add another one but then that would mean $bp6would
be smaller than $bp5 which is exactly the confusion we want to avoid.

So please everyone tell me if you like xsmall, small, medium, large,
xlarge and are cool with say mid-"first variable"-"second-variable" for
your in betweens such as mid-large-xlarge and if you need to add more doing
xxsmall or xxlarge.

meaning default wise we would see
$xsmall, $small, $medium, $large, $xlarge

possibly seeing this often
$xsmall, $small, $mid-small-medium, $medium, $mid-medium-large, $large
xlarge

This would be mean you could potentially have :
$xxsmall, $mid-xxsmall-xsmall, $xsmall, $mid-xsmall-small, $small,
$mid-small-medium, $medium, $mid-medium-large, $large, $mid-large-xlarge,
$xlarge, $mid-xlarge-xxlarge, $xxlarge

I have to be honest if you are using 13 breakpoints I have to question
what you are doing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHnjh6WqCauFhO63zJkA1Vox9K83Y7wnks5qF5NhgaJpZM4Ik4Gd
.

[michaelspellacy]

I have to be honest if you are using 13 breakpoints I have to question what you are doing.

Depends on the design. The more intricate the design is, the more breakpoints you have. Often, you can tell a good responsive design from a bad one by the amount of breakpoints that are present. It's a pretty good gauge. :-)

[michaelspellacy]

Or you could be really bad at RWD, so maybe not! :-)

[michaelspellacy]

@Brockenstein Any progress on coming closer to a finalized standard we can add to our documentation?

[Brockenstein]

@michaelspellacy It's been 9 days since I emailed out the devs and it looks like we are good with the following.

$xxs
$xs
$s
$sm
$m
$ml
$l
$xl
$xxl

More than likely common breakpoints will be

$xs
$s
$m
$l
$xl

The suggested sizes below would just be what we put in the default code and would be perfectly acceptable for each developers on each project to change, maybe in the default sass the sizes could be:

$xxs: 360px;
$xs: 480px;
$s: 550px;
$sm: 600px;
$m: 800px;
$ml: 960px;
$l: $max-width;
$xl: 1200px;
$xxl: 1400px;

If you needed additional Media queries you could do
xxxs or xxxL

If for some reason you need a range of variables for a specific section of your site you could add a name to the variables if the above options just aren’t enough like the following:

$banner-s
$banner-m
$banner-l
$banner-xl

and so forth.

Before we put in a ticket to change this for the default code, I suggest we agree on a mixin and get both of those in, especially since we don't want the mixin we use make us rethink our variables.

[michaelspellacy]

So, we never resolved this. I came across an interesting article today. I think the author's thoughts fit in well with what we are attempting to do in adopting a standard/naming convention. Give it a read and let me all know what you think:

https://medium.freecodecamp.com/the-100-correct-way-to-do-css-breakpoints-88d6a5ba1862

[Brockenstein]

@michaelspellacy O i thought we had agreed but like I said no ticket has been made due to no mixin chosen yet. I have gone ahead and been using

// breakpoint variables
$xxs: 360px;
$xs: 480px;
$s: 566px; // equal to mid-small
$sm: 600px;
$m: 800px; // equal to end-small
$ml: 960px;
$l: 1000px;
$xl: 1200px;
$xxl: 1400px;

$max-width: 990px; // Only to be used as max width not a breakpoint

I read the article and it seems to go against your idea on obscuring and not being device specific which is why we landed on the variables I just mentioned. Are you changing your viewpoint on this? I personally don't care for the way he uses his breakpoints. One of the comments from others says "Ideally you want to choose your breakpoints around your content and design, not around devices." Which I tend to agree with. When I think responsive I think a perfectly flowing site. Not a site with few break points just for devices. After all even on a table for phone someone can pull up two windows side by side halfing their resolution of their device. So you never know how people will use it.

[michaelspellacy]

@Brockenstein This is pretty much how we are all doing it now. Will add to standards doc. Finally!