Approach for limits inclusion and exclusion of resolutions and sizes mixins
meduzen opened this issue · comments
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
.
Edition of the issue description finished.
Also: naming is hard! 😅