CSS Nesting Conventions

Loved the video on nesting, Kevin - really exciting to see the power that might have. One thing which occurred to me was around the nesting of media queries into other rules:
H1 {
@media (max-width: 768px) {
....
}
}
H1 {
@media (max-width: 768px) {
....
}
}
I guess this runs the risk of having your breakpoints repeated throughout your CSS file, meaning a bit F&R job if they need adjusting globally. Is it better to keep breakpoint media queries at the top level, and restrict nesting for local overrides? I did, for a moment, wonder if the media query value could come from a CSS variable - making it possible to define breakpoints once and reuse - but sadly it appears not 😦
7 Replies
dys 🐙
dys 🐙16mo ago
This article explains that it's because media queries are outside the document structure while custom properties are defined within. https://bholmes.dev/blog/alternative-to-css-variable-media-queries/ It mentions environment variables which the docs say will work in media queries: https://developer.mozilla.org/en-US/docs/Web/CSS/env
Kevin Powell
Kevin Powell16mo ago
They are working on custom break points, which I'm really looking forward to. It'll look something like this: @custom-media --narrow-window (max-width: 30em); Also, I'm 90% sure variables work within @container queries... which makes me wonder why they can't make them work within regular media queries, but 🤷 I always just have a media query directly after a selector anyway, so nesting it is just easier. It's easy enough to do a find and replace if you need to update a lot of breakpoints at once (or just use Sass, which you can use variables for in media queries 😄 )
Wouter Schaap
Wouter Schaap16mo ago
I have played with Custom Properties and media queries, thing is, you can change the value of a custom propery inside a media query to be smaller than for example the media queries min-width. That way you'd get into some sort of an infinite loop.
Kevin Powell
Kevin Powell16mo ago
Ah, right, that's why they don't do it 👍
Kiers
Kiers16mo ago
Thanks - I'll take a look 🙂 Thanks very much Kevin - that's really helpful. I'm never sure whether to do a big media query which defines all the changes for that breakpoint, or focus on how grouping behaviour for individual elements. That custom media tag sounds like it'll make life clearer. I do like the idea of using a label in the MQ so it has meaning beyond just a number. Makes a lot of sense - good point. Thanks
Wouter Schaap
Wouter Schaap16mo ago
@kiers_m I have found that a lot of what needs to change on media queries is usually just some pixel or rem values. This can easily be done with custom properties and setting those to new values inside the media queries. That way you can name it really clearly and you don't have to state both property and value. I find it usually makes my code more readable. Also it depends. Sometimes so much changes on query it really is better to define a whole new area for it in CSS. But usually, keeping media queries close to where the element lives makes it easier to see everything that happens to that element through all the various screen and media sizes. This usually has my preference. I'd rather define the same media query multiple times with different content, instead of one big block of media query.
WebMechanic
WebMechanic16mo ago
I love @custom-media --tiny-bit and @custom-selector :--headings Still requires PostCSS preset-env. Very useful, but IDE support is bad and they all get squiggly lines 😦
Want results from more Discord servers?
Add your server