Approach for limits inclusion and exclusion of resolutions and sizes mixins

[meduzen]

Missing in Double Dash

Currently, the mixins for min-width, max-width, min-resolution and max-resolution all generate features queries following a mobile-first approach.

Using --w-from (or --resolution-from), the resulting custom media query leaves the value passed to the mixin as is. But using the -to mixins excludes the value: it stops before the passed limit.

@include --w-from('name…', 20em); // (min-width: 20em) 👍 as expected
@include --w-to('name…', 70em); // (max-width: 69.999em) 😮 stops just before

Double Dash mixin	generated CSS	math operator
w-from(…, 70em)	min-width(70em)	width >= 70em
doesn’t exist	min-width(70.001em)	width > 70em
w-to(…, 70em)	max-width(69.999em)	width < 70em
doesn’t exist	max-width(70em)	width <= 70em
w-from-to(…, 30em, …, 70em)	min-width(30em) and max-width(69.999em)	30em < width <= 70em

Why --from- and --to-

As Double Dash purpose is to considerably increase efficiency and maintainability around media queries, the current prefixes (from and to) have been chosen because they are very short to write and, using the --w mixin that generates combined media queries, it particularly feels great to have a custom media query named --nav-collapsed-to-nav-expanded.

However, from … to implies inclusion, and the use of these prefixes in Double Dash currently means “inclusion of the smaller bound, exclusion of the greater one”, which doesn’t feel semantically right nor easy for people not used to a mobile-first approach (and sometimes, you just don’t want the mobile-first approach).

The decision to make

Ideally, Double Dash should provide a solution for all scenarios (<, <=, >=, >).

In any case, this would be a breaking change as it changes the to- output.

Here are some output proposals based on this code:

$nav-breakpoints: (
  'nav-expanded': 90em,
);

@include --w($nav-breakpoints);

Proposal 1: before, after

--before-nav-expanded // (max-width: 89.999em)
--to-nav-expanded // (max-width: 90em)
--from-nav-expanded // (min-width: 90em) // or just --nav-expanded
--after-nav-expanded // (min-width: 90.001em)

Proposal 2: __

--to-nav-expanded__ // (max-width: 89.999em)
--to-nav-expanded // (max-width: 90em)
--from-nav-expanded // (min-width: 90em) // or just --nav-expanded
--__from-nav-collapsed // (min-width: 90.001em) // or just --__nav-collapsed

And when it comes to ranges combinations, it could lead to:

--nav-collapsed-to-nav-expanded //  (min-width: 45em) and (max-width: 90em)
// […] more in between combinations
--__nav-collapsed-to-nav-expanded__ //  (min-width: 45.001em) and (max-width: 89.999em)

Both proposals could live together. I see the first proposal as the default one because it generates custom media queries with very explicit names, and the second proposal as an alias or shorter syntax.

More words

Other foreseeable short words are min, max, start, end, until (or till), downto, upto, but they convey the same meaning as from and to.

[meduzen]

Edition of the issue description finished.

[meduzen]

Also: naming is hard! 😅