{"id":375607,"date":"2022-12-01T05:59:06","date_gmt":"2022-12-01T13:59:06","guid":{"rendered":"https:\/\/css-tricks.com\/?p=375607"},"modified":"2022-12-01T14:25:32","modified_gmt":"2022-12-01T22:25:32","slug":"digging-deeper-into-container-style-queries","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/digging-deeper-into-container-style-queries\/","title":{"rendered":"Digging Deeper Into Container Style Queries"},"content":{"rendered":"\n

I wrote up some early thoughts on container style queries<\/a> a little while back. It’s still early days. They’re already defined in the CSS Containment Module Level 1 specification<\/a> (currently in Editor’s Draft status) but there’s still a couple of outstanding discussions taking place.<\/p>\n\n\n\n

The basic idea is that we can define a container and then apply styles conditionally to its descendants based on its computed styling.<\/p>\n\n\n\n

@container <name>? <conditions> {\n  \/* conditional styles *\/\n}<\/code><\/pre>\n\n\n\n
The best example I’ve seen so far is removing italics from something like <em><\/code>, <i><\/code>, and <q><\/code> when they are used in a context where content is already italicized:<\/p>\n\n\n\n
em, i, q {\n  font-style: italic; \/* default UA behavior *\/\n}\n\n\/* When the container's font-style is italic, remove italics from these elements. *\/\n@container style(font-style: italic) {\n  em, i, q {\n    font-style: normal;\n  }\n}<\/code><\/pre>\n\n\n\n
That’s the general idea. But if you didn’t know it, Miriam Suzanne, who is an editor of the spec, keeps an ongoing and thorough set of personal notes on container style queries<\/a> that is publicly available. It was updated the other day and I spent some time in there trying to wrap my head around more nuanced aspects of style queries. It’s unofficial stuff, but I thought I’d jot down some things that stood out to me. Who knows? Maybe it’s stuff we can eventually look forward to!<\/p>\n\n\n\n\n\n\n
Every element is a style container<\/h3>\n\n\n
We don’t even need to explictly assign a container-name<\/code> or container-type<\/code> to define a style container because everything is a style container by default.<\/p>\n\n\n\n
So, you see that example above that removes italics? Notice it doesn’t identify a container. It jumps right to the query using the style()<\/code> function. So, what container is being queried? It’s going to be the direct parent of the elements<\/strong> receiving the applied styles. And if not that, then it’s the next nearest relative container<\/strong> that takes precedence.<\/p>\n\n\n\n
I like that. It’s very CSS-y for the query to search up for a match, then continue to bubble up until it finds a matching condition.<\/p>\n\n\n\n
It was hard for my little brain to understand why we can get away with an implicit container based on styles but not so much when we’re dealing with dimensional queries, like size<\/code> and inline-size<\/code>. Miriam explains it nicely:<\/p>\n\n\n\n
Dimensional queries require css containment<\/em> on the size, layout, and style of the container in order to prevent layout loops. Containment is an invasive thing to apply broadly, so it was important that authors have careful control over what elements are (or are not) size containers.<\/p>
Style-based queries don\u2019t have the same limitation. There is already no way in CSS for descendant styles to have an impact on the computed styles of an ancestor.<\/strong> So no containment is required, and there are no invasive or unexpected side-effects in establishing an element as a style query container<\/em>.<\/p>(Emphasis mine)<\/cite><\/blockquote>\n\n\n\n
It all comes down to consequences \u2014 of which there are none as far as everything being a style query container right out of the box. <\/p>\n\n\n\n