[6.2] breakpoint names hardcoded in _breakpoints.scss?

[erutan]

I'm not using default classes for much, using F6 semantically with SASS. I had made some custom breakpoints that were (to me) more clearer than small, medium, etc. I'm now getting the following error when compiling F6 (via gulp-sass from the zurb template) that I didn't have in previous versions.

Error in plugin 'sass'
Message:
    bower_components/foundation-sites/scss/util/_breakpoint.scss
Error: Your list of breakpoints (defined in $breakpoints) must include one named "small" and one named "medium".
        on line 22 of bower_components/foundation-sites/scss/util/_breakpoint.scss
>>   @error 'Your list of breakpoints (defined in $breakpoints) must include one 
   --^

There's an easy fix around this obviously, but it'd be nice if things were a bit more agnostic like before. :)

[gakimball]

We did this because there are many places in the framework where we use the word "small", and allowing that name to change was opening us up to bugs. So, we introduced a new rule that you have to have a breakpoint defined as small: 0.

If you think there's a way around that, we can look at a solution.

[erutan]

I can live with small (I was using single-column) and medium - I generally don't just have typical device + wide breakpoints but create a new semantic one whenever I have a use for it (e.g. collapse-cards, breakout-info-to-columns, etc).

What I ended up doing was just using small for my base breakpoint, and created a medium one alongside my multi-column (they mirror each others values), so I do don't have to use medium anywhere in my SASS. It's just clearer what things mean that way (opinion).

I haven't dug enough into the guts of F6 to give a technical solution - I've just been using it on one prototype and have done so when needed, which hasn't been too often.

[andycochran]

@gakimball Would something like a $zero-breakpoint-name variable help?

e.g.:

/// The name of mobile-first styles (styles without a media query) and the class for styles on screens smaller than the lowest non-zero breakpoint. 
/// @type String 
$zero-breakpoint-name: small !default;

[erutan]

I was thinking of having assignable values as well. There'd have to be a little explanation of them needing to also be in the SASS map, but it seems reasonable. Medium is probably the most perplexing one, as it's really more like "we're beyond needing a layout for a phone" but there are often some breakpoints between that and small.

I think for the future (F7?) if there are going to be hardcoded breakpoints to have small be renamed to something like base, zero, etc. It really functions as a foundation / floorboard for other queries to build upon.

[DaSchTour]

Why was the smallest breakpoint hardcoded in such a way in 6.2? I had defined two different breakpoints for small devices, xsmall and small because sometimes I need to tweak the layout for phones with 320px width. The xsmall breakpoint has 0px and it all worked until 6.2 introduced this "check". Now I have to rename all my breakpoints and change all my HTML?

[erutan]

@DaSchTour #8257 (comment)

semi-related reading if you're curious (wasn't happy with breakpoints being spread throughout the framework, namespacing conflict #7773)

[mwinkelm]

I just want to use Foundation's grid for a recent project and also want to use other namings of breakpoints. As I'm not using (including) the modules, that are dependent on the breakpoint names this issue should not affect me at all.

+1 for @andycochran's idea to use variables for breakpoint names throughout the framework.

[gakimball]

I can get behind using an internal variable to alias "small", but I think it's fine as a purely internal variable, like $-zf-smallest or something. We an abstract that complexity away for the user and have it Just Work regardless of what their smallest breakpoint is named. We do need to keep the rule that one breakpoint is 0, however.

[gakimball]

Pull request open here: #8318

[erutan]

The error says that foundation requires small and medium breakpoints set - small is easy to take care of, but you can't assume the second largest breakpoint takes the place of medium.

[gakimball]

@erutan Right, that's what makes this tricky—the framework uses small and medium, so the codebase is easier to reason about if we can guarantee those two words are always there.

Most components only make changes from small to medium, which is more or less "mobile to desktop". If we can rework the components to only reference one threshold, like medium, then maybe we can also have a $global-desktop-threshold, or something more elegantly named, to define that cutoff.

Does that make senses?

[erutan]

Yeah, just wanted to clarify. :)

[tomByrer]

$-zf-smallest Would that be phone smallest, or smart-watch smallest? ;)

I did some research using statcounter.com; found there are still many small screens in use (21% of mobile are 640x640 or smaller) & huge desktop screens are increasing (18% of desktops/laptops are 1700px wide or larger).

[andycochran]

Smallest is smallest. It's not relative. It's zero pixels wide and up.

[gakimball]

Merged #8318, although I'm still interested in solving the (potential) problem of medium being hardcoded. small is no longer hardcoded, but medium still is.

[proimage]

I think the problem with small being hard-coded wasn't as much that it was called small, but that it was mandatorily the breakpoint that was set to zero; for example I had a tiny breakpoint set in 6.1.x that broke on upgrading.

A medium breakpoint needing to exist is less of an issue - there will (should?) always be one, and its dimension can be flexible, so the aesthetic issue of it having to be named medium is minor, IMO.

[tomByrer]

that small was mandatorily the breakpoint that was set to zero; for example I had a tiny breakpoint set in 6.1.x that broke on upgrading.

That was part of my sarcastic remark above. I ended up with calling a breakpoint smallmedium & let small ~= tiny.

[andycochran]

I think "small" is a semantic issue that'll continue to plague Foundation well into the future. We might be better served by setting $-zf-zero-breakpoint to zero by default.

$breakpoints: (
  zero: 0,
  small: 320px,
  medium: 640px,
  large: 1024px,
  xlarge: 1200px,
  xxlarge: 1440px,
) !default;

$-zf-zero-breakpoint: zero !default;

[proimage]

I like that direction of thinking, but keep in mind that in that case, a zero breakpoint would cover widths up to and including 319px, which isn't strictly logical. Something like smallest is more semantically accurate, although it is rather long.

Perhaps tiny is a good compromise, although it loses the "there's nothing smaller than this" semantic meaning. It's nice and short, and intrinsically means something smaller than small, so it has that going for it... dunno.

[andycochran]

@proimage Fair point regarding "up to 319."

Although, I still think zero makes sense logically, especially from a mobile-first perspective. A breakpoint is a point, not a range. The only place zero gets awkward is with @include breakpoint(zero only)—which isn't very logical because mobile-first. Any zero only styles should just be default styles and overridden by the next breakpoint.

(All that said, this debate's been had before. The Zurb folks have put lots of thought into this.)

[proimage]

True - breakpoints are just points, not ranges. However, their names as used in Foundation cover or affect ranges, so it is sensible to name them something that suits both a range and a point.

With that in mind, the only name I can really recommend using as the default breakpoint name is smallest.

[DaSchTour]

Just for clarification. There is no need to set $-zf-zero-breakpoint.
Basicly always the smallest breakpoint name is loaded into $-zf-zero-breakpoint.
So everybody can name the smallest breakpoint as he wants.
But I don't think we should change the default names, as the term small, medium, large are also used within other similar frameworks and are very common.

[kball]

@andycochran what is your sense as to the current state of this? Can we close this?

[andycochran]

Yup. I'm closing this. The conversation goes into the weeds a bit. But the main issue has been resolved. If the related stuff that came up continues to be a problem, we'll create new (more specific) issues.