{"id":5761,"date":"2025-05-06T18:53:28","date_gmt":"2025-05-06T23:53:28","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=5761"},"modified":"2025-05-06T18:53:29","modified_gmt":"2025-05-06T23:53:29","slug":"using-container-query-units-relative-to-an-outer-container","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/using-container-query-units-relative-to-an-outer-container\/","title":{"rendered":"Using Container Query Units Relative to an Outer Container"},"content":{"rendered":"\n

Recently, Matt Wilcox posted on Mastodon<\/a>:<\/p>\n\n\n\n

\n

The fact you can\u2019t specify which<\/em> container for container query units is a ballache. The moment you have nested containers you\u2019re [screwed]; because if you want the calculated gap from the row\u2019s container; but you\u2019re inside a nested container\u2026 tough. Your units are wrong. And you can\u2019t just say \u201cno; not relative to this<\/em> container; relative to the named outer container!\u201d<\/p>\n<\/blockquote>\n\n\n\n

First off, if you’re not familiar with container queries and container query units, you can check out one of the many resources on the topic, for example this\u00a0interactive guide<\/a>\u00a0by Ahmad Shadeed, which I believe is the most recent out of all the detailed ones I’ve seen. As always, the date of the resources used is important for web stuff, especially since these units in particular have changed their name since\u00a0they were first proposed<\/a>\u00a0and we got an early draft of the spec.<\/p>\n\n\n\n

Now, the problem at hand: let’s say we have an .inner-container<\/code> inside an .outer-container<\/code> – they are both made to be containers:<\/p>\n\n\n

[class*='container'<\/span>]<\/span> { container-type<\/span>: size }<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
We want any .inner-child<\/code> of the .inner-container<\/code> to be able to use length values set in container query units relative to the .outer-container<\/code> (more precisely, to its content-box<\/code> dimensions). The problem is, if we do something like this (a 20cqw<\/code> light blue strip at the start of the gradient going towards 3 o’clock):<\/p>\n\n\n
.inner-child<\/span> {\n  background<\/span>: linear-gradient<\/span>(90deg<\/span>, #0<\/span>a9396 20<\/span>cqw, #0000<\/span>)\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
… then the 20cqw<\/code> value is 20%<\/code> (a fifth) of the content-box<\/code> width of the .inner-container<\/code>. This can be seen below, where we have purple guidelines 20%<\/code> of the width apart.<\/p>\n\n\n\n
\"Screenshot
what 20cqw represents<\/figcaption><\/figure>\n\n\n\n
But what we want is for that 20cqw<\/code> value to be 20%<\/code> of the content-box<\/code> width of the .outer-container<\/code>.<\/p>\n\n\n\n
Strictly for the queries themselves, we could do something like this:<\/p>\n\n\n
.outer-container<\/span> { container<\/span>: outer\/ size }\n.inner-container<\/span> { container<\/span>: inner\/ size }\n\n@container<\/span> outer (min-width:<\/span> 500px<\/span>) {\n  .inner-child<\/span> { background<\/span>: darkorange }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
This allows us to set certain styles on the .inner-child<\/code> elements based on where the width<\/code> of the .outer-container<\/code> (which isn’t the nearest<\/em> container for .inner-child<\/code>) is situated relative to the 500px<\/code> threshold.<\/p>\n\n\n\n
But we cannot do something like this to specify which container should be the one that the query units used on .inner-child<\/code> are relative to:<\/p>\n\n\n
.inner-child<\/span> {\n  \/* can't do this *\/<\/span>\n  background<\/span>: linear-gradient<\/span>(90deg<\/span>, #0<\/span>a9396 outer 20<\/span>cqw, #0000<\/span>)\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Nor can we do this:<\/p>\n\n\n
.inner-child<\/span> {\n  \/* can't do this either *\/<\/span>\n  --s<\/span>: outer 20<\/span>cqw;\n  background<\/span>: linear-gradient<\/span>(90deg<\/span>, #0<\/span>a9396 var(--s), #0000<\/span>)\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
However, we are<\/em> getting closer!<\/p>\n\n\n\n
What if we move the --s<\/code> variable uspstream? After all, a 20cqw<\/code> length value set on the .inner-container<\/code> is 20%<\/code> of the content-box<\/code> width of its nearest container, which is the .outer-container<\/code>. This would mean our code becomes:<\/p>\n\n\n
[class*='container'<\/span>]<\/span> { container-type<\/span>: size }\n\n.inner-container<\/span> {\n  --s<\/span>: 20<\/span>cqw;\n  background<\/span>: \n    repeating-linear-gradient<\/span>(45deg<\/span>, #bb3e03 0<\/span> 5px<\/span>, #0000<\/span> 0<\/span> 1em<\/span>) \n      0<\/span>\/ var<\/span>(--s) no-repeat\n}\n\n.inner-child<\/span> {\n  background<\/span>: \n    linear-gradient<\/span>(90deg<\/span>, #0<\/span>a9396cc var(--s), #0000<\/span>)\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\"Screenshot.
screenshot of result<\/figcaption><\/figure>\n\n\n\n
For the .inner-container<\/code> the 20cqw<\/code> of the --s<\/code> is taken to be 20%<\/code> of the content-box<\/code> width of its nearest container, .outer-container<\/code> (dashed dark blue boundary). However, for the .inner-child<\/code>, the 20cqw<\/code> of the --s<\/code> aren’t taken to mean the same value. Instead, they are taken to mean 20%<\/code> of the .content-box<\/code> width of the .inner-container<\/code> (dotted dark red boundary).<\/p>\n\n\n\n
Boo!<\/p>\n\n\n\n
But what happens if we also register --s<\/code>?<\/p>\n\n\n
@property<\/span> --s {\n  syntax<\/span>: '<length<\/span>>';\n  initial-value<\/span>: 0px<\/span>;\n  inherits<\/span>: true<\/span>\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\"Screenshot.
desired result<\/figcaption><\/figure>\n\n\n\n
I hope you’ve enjoyed this little trick.<\/p>\n\n\n\n
Where would you use this?<\/p>\n","protected":false},"excerpt":{"rendered":"
Container units (e.g. cqi) are only able to reference the closest container. But if you register a custom property and set that higher up, you can get your hands on other containers units.<\/p>\n","protected":false},"author":32,"featured_media":5803,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[47,48,7,180],"class_list":["post-5761","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-container-queries","tag-container-units","tag-css","tag-custom-properties"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2025\/05\/Using-Container-Query-Units-Relative-to-an-Outer-Container.jpg?fit=1140%2C676&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/5761","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=5761"}],"version-history":[{"count":6,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/5761\/revisions"}],"predecessor-version":[{"id":5805,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/5761\/revisions\/5805"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/5803"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=5761"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=5761"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=5761"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Bingo, this works<\/a>!<\/p>\n\n\n\n
We also give the .inner-container<\/code> a similar background<\/code> restricted to 20cqw<\/code> from the left along the x<\/em> axis and make the .inner-child<\/code> semi-transparent, just to check if the --s<\/code> values overlap (which is what we want, --s<\/code> being 20%<\/code> or a fifth of the .outer-container<\/code> width). However, this fails<\/a>, as it can be seen below:<\/p>\n\n\n\n