Feature: add media breakpoints

[niklasmh]

This is a proposal on how to solve the breakpoint problem mentioned in #29.

Fixes #29.

Story:

[niklasmh]

Probably a little over-engineered, but I think this will do the job.

[plusk]

This seems like a lot. First of all it would be nice to have an absolute minimum, instead of 0px. Design systems are more than just mixins, it's also a guide for developers on how to use the shit we're implementing. We need to find the lowest resolution we're going to care about. Not that it needs to be used when styling if going mobile-first, but it should be written down somewhere.

As for the rest, I just think there are too many options, without a lot of guidance as to which to use. We have ranges and min-breakpoints and max-breakpoints, but why? I think we should only use one of the options and stick to that. Personally I think max-breakpoints work fine. Like I mentioned in the issue, using max-breakpoints lets you write for mobile first, then scale up for different resolutions.

TL;DR: add a minimum, decide on a breakpoint style

[niklasmh]

I have no opinions about the minimum, thus at 0px nothing will be visible anyway so it does not make sense to use. I will add 320px as a minimum just to have something to build upon. An idea is to just support down to 0px, but make sure the page does not squish further than 320px using min-width on body.

Regarding the options. I fully agree there are just too many. Usually, we have mobile, tablet and desktop as analogies to the widths, but now I tried adding a fourth breakpoint and it got way too complex. We could use names like xs, s, m, l, xl, which gives room for more breakpoints, but then developers may mix the use cases. I think removing the "largeDesktop" would make things much simpler and intuitive.

Regarding the option style. I think that keeping the option to style for device-only, together with min and max, has some advantages. Use case: You want to specify a few styles for the tablet. Using a minimum breakpoint you then need to turn off the styling on desktop (or using maximum you need to turn off styles in mobile). If you have a tablet-only query you do not get side effects and do not need extra code to make up for it. Though there may be a minimum of use cases where this is a big deal. I just like having options, and for me, it seems logical to have.

Disclaimer: This is probably the first time thinking of doing something like this, so I may change my mind in the near future.

[plusk]

Having a widescreen option can seem like a lot, but remember that it would affect everyone using a 1080p screen or above with a maximized window (assuming no upscaling). Sure, we wouldn't add a lot of custom styles for it, it's more for stuff like typography so that it's legible at different monitors. You naming it "largeDesktop" is on you, I'd go for "tablet, desktop, widescreen" as the three breakpoints, where mobile would be the default to be overriden if needed.

Choosing breakpoints isn't as much of an opinion thing as an analytics thing. We have Google Analytics, have a look at them and see what people use. In some cases a11y should be taken into consideration, but there aren't any hard guidelines for resolution there. You could read into stuff like this (which will be extended to require 400% from 2020 iirc), but eh. So when choosing a minimum, we should go based on our users. 320px width is the "safest", but if we feel comfortable with it, then we can take it up a step to 375px.

Like you mentioned, naming the breakpoints like xs, s, m, l, xl, etc, mostly adds confusion. Sure, naming it the "tablet" range doesn't cover every tablet, but it's a decent guideline.

As for options, I get that it can be comfortable to have device-specific styling, but design shouldn't be custom from device to device. It should be the same skeleton HTML skinned differently with CSS. That's probably an opinion on my part, but I think restricting your options reduces the likelihood of people making lazy and messy layouts. Having options is nice, sure. It's comfortable, but I don't think it's better.

Regardless of device-specific breakpoint ranges, I think we should decide on either having min or max. Having both doesn't give you more options, it just makes it more messy, as they will inevitably be used at the same time. They're both fine, I prefer max-based breakpoints. Feel free to Google around and find a million discussions about it, it's more of a design thing. Either you write with desktop/widescreen as default, or you write mobile-first. Personally I think it's easier to think mobile-first and scale up if needed, because oftentimes you don't have to do a lot of work. If you start designing your desktop, squeezing that on to a smaller screen can be a hassle.

TL;DR: I'd like having a widescreen option, but we can go without it at first, and then see if we want to add it later, wouldn't be an issue. I prefer choosing either min, max, or both combined as the standard. Doesn't really matter which, just stick to it. Having more options leads to mess down the road. I prefer min-based breakpoints.

[niklasmh]

I have thought and read a little more about the topic and it seems that you are on to something.

Let us say we design for mobile-first and use min-widths (I totally agree that using max-widths also would create confusion). We may then say the users write something like:

@media ${media.tabletAndUp} {...}

Advantage of using the long name, tabletAndUp, is that the users intuitively know what will happen. This is just an example I found elsewhere. Counterexample: Using media.tablet may lead to confusion.

We could also add an option with tabletOnly or just tablet, meaning exactly what it describes. This is also just an example of how the naming could end up like.

@media ${media.tabletOnly} {...}

Just forgetting about the max-width style makes sense, thus keeping the exact device option still makes sense to me.

I think if we go for the min-width style, the "widescreen" (nice we have a name for it) can just be included as well as it has no effect on the other min-widths.