I've created many NPM packages and invented many hacks focused on helping us all easily create beyond what's typically considered possible. It drives me.
This idea, I swear was given to me by higher powers and backed with so much excitement and perfectly sequenced synchronicities... Nobody would believe the details.
A new breakpoint-system
Using my tan(atan2()) scalar idea, I take a <length> like 100cqw and turn it into its pixel equivalent as a <number>.
For example, 1rem length becomes the number 16.
Writing up to 10 user-configurable <number> vars as pixel-based breakpoint locations, (maybe called sm, md, lg, etc)
I combine it all with abs(), clamp(), min(), max(), and calc() into registered <integer> results to create bit flags. 0 or 1.
Each flag represents the results of comparing those breakpoints to 100cqw as a number. Is the number less than the breakpoint? Greater than or equal to? In between two of them?
100cqw becomes the width to query against, the bit flag comparisons are the results of each query.
This opens up 3 API paths
calc() switches, @container style() queries, and if(style()) queries.
aspect-ratio: calc(
var(--qlt-md) * (5 / 7) +
var(--qin-md) * (4 / 3) +
var(--qgte-lg) * (16 / 9)
);
.biggest-heading {
@container style(--qlt-md: 1) {
font-size: 20px;
}
@container style(--qin-md: 1) {
font-size: 24px;
}
@container style(--qgte-lg: 1) {
font-size: 28px;
}
}
grid-template-areas: if(
style(--qlt-md: 1): "a" "b" "c" "d" "e" "f";
style(--qin-md: 1): "a a" "b c" "b d" "b e" "f e";
style(--qgte-lg: 1): "a a a a" "b b c d" "b b f e";
);
calc() can do all of these at the same time using keyframes of an always-paused animation, setting all 3 properties in each keyframe.
You choose your API to choose your user reach. The library reach is 91% as of April 2026.
This is the solution to web development.
Designers win. Developers win. Accessibility wins. Your users win.
Even the consciousness of the idea itself wins because it becomes a source of ease for everyone involved.
Everything we've come to accept goes away as everything we've hoped for takes its place. With less effort.
Automatic accessibility win #1
100cqw does not include the scrollbars, media queries do. If a user's system accessibility is configured for scrollbars to always be on and maybe even set to a bigger size, historically you deliver your 1024 breakpoint design in an unknowable smaller available space.
For years engineers have been left to work around it without even reliably being able to detect it in CSS, let alone measure it or have the skill to adjust a designer's vision appropriately for every potential scenario.
With breakpoint-system, scrollbar gutters biting into a 1024 viewport just won't trip the 1024 breakpoint yet so there's plenty of room for the smaller design still.
and it gets so much better later because of Breakpoint Units.
Designer and developer wins that are such a relief, your first response may be to doubt it.
We use rem and its decimal fractions everywhere because it is the best solution to support our user's system font size increases for accessibility.
Just use pixels anyway.
We're supposed to use
emfor breakpoints for the same reason, but it's extremely rare to see it in practice.
No guilt. Keep using pixels.
Designers, devs, and project managers know the max length of our content, especially titles, and we already plan for that as a team.
Keep doing that.
Which of us is responsible for making designs not look terrible, squished, janky, cut-off, overflowing, or just broken when the user's system font size is 20px - a full 25% bigger?
Pixels don't do that, so let's all just use pixels.
We want a fluid design that scales with the view width, respects rem, is aware of the starting size, surrounding breakpoints, and ending size, and isn't a nightmare to re-calc() if designs change later.
Only the breakpoints you choose to include for designs of this specific layout/component exist as screen sizes.
Like designing physical playing cards. It's finally safe to ignore all other scenarios and in-between screen sizes.
So pixels are the best choice here too.
Pixels. :)
You never need to use rem again.
Breakpoint Units take care of all of this automatically in the background and they map 1:1 with your pixels.
Automatic accessibility win #2
For over a decade authors like Zell Liew have written about the importance of using em in your media query breakpoints yet we have largely collectively avoided it. There are two main reasons for this: pixels are easier to work with, and you need to make adjustments to every breakpoint design and every block of css inside every media query to allow the intended effect without causing weird max caps in the wrong scenarios, etc. Effectively it doubles the effort to be mindful in both design and dev.
Taking a step back for a moment.
When we tan(atan2()) 1rem into a number, and divide it by the expected 16, we get a scalar telling us how much the user has adjusted their system font size for accessibility.
20 / 16 = 1.25
We shift your pixel based breakpoints for this user by that amount.
This is equivalent to what using em in media query breakpoints does.
HOWEVER, when combined with this pixel philosophy of my breakpoint-system and Breakpoint Units, your user will never see text smaller than their preference, your designs won't break, they don't have to pinch-pan-zoom, nothing overflows.
Breakpoint Units automatically show the previous design, magnified beyond where it would have changed to a bigger design and flawlessly meets the requirement.
Their experience of your designs is exactly the same as any other user's experience, just bigger as if the website thought their tablet was a phone and scaled up to fill their screen.
Neither designers nor devs need to plan for this or make extra effort. It happens in the background automatica11y.
The smallest breakpoint has no smaller design to show.
Technically this is a caveat - but it requires no new effort.
The status quo for your smallest designs remains important:
Nearly everything is just stacked in a single column, nothing is vertically constrained, and break word is expected. In your smallest defined breakpoint range only, our typography breakpoint units directly express the user's magnification.
(Breakpoint Units never actually expand for the system font size outside of that smallest range. The math and UX just makes it seem like that's the reason they've grown to meet the requirement!)
Hands-on learning
@propjockey/breakpoint-system
You will never build a personal site or app again without using breakpoint-system as the foundation once you've experienced it. Neither will I.
It has solved so many problems, some over a decade old, for so many different groups of people at once, and packaged the API so well, that any full-feature design system built in the future will either use @propjockey/breakpoint-system directly as a foundation or it must ...replicate it to keep up.
Once your team has begun experiencing the zero friction handoffs in addition to all of the relief it delivers on the surface, you will agree with what I already know is true
I have created the new baseline expectation.
https://propjockey.breakpoint-system.com
https://github.com/propjockey/breakpoint-system
https://www.npmjs.com/package/@propjockey/breakpoint-system
Open Contact 👽
Please do reach out if you need help with any of this, have feature requests, or want to share what you've created!
| PropJockey | CodePen | DEV Blog | GitHub |
|---|---|---|---|
 |
 |
 |
 |
| Mastodon | X | Bluesky | |
|---|---|---|---|
 |
 |
 |
 |
My heart is open to receive abundance in all forms,
flowing to me in many expected and unexpected ways.
| PayPal | Ko-fi | Venmo |
|---|---|---|
 |
 |
 |
| BTC | XRP | ETH |
|---|---|---|
 |
 |
 |
| bc1qe...usgn9 | rw2ci...nWKQg : 459777128 |
0x674...beF54 |
Top comments (0)