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:
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
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
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 😄 )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.
Ah, right, that's why they don't do it 👍
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
@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.
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 😦