Early Days of Container Model Queries | CSS-Tips

We’re nonetheless in suuuuuper early days with container queries. Too early for broad browser help, however Chromium already helps it, Safari began supporting it in model 16, and Firefox is presumably not far behind.

Most early days conversations revolving round container queries often examine the syntax to media queries.

/* Stacked flex container */
.publish {
  show: flex;
  flex-direction: column;
}

/* Change path when viewport is 600px or wider */
@media(min-width: 600px) {
  .publish {
    flex-direction: row;
  }
}

/* Outline the container */
.posts {
  container-name: posts;
  container-type: inline-size;
}

.publish {
  show: flex;
  flex-direction: column;
}

/* Question the container's min-width */
@container posts (min-width: 600px) {
  /* Change types when `posts` container is 600px or wider */
  .publish {
    flex-direction: row;
  }
}

Each of those are making queries for min-width: 600. The distinction is that the media question is trying on the viewport’s width to set off these model adjustments whereas the container question is trying on the computed width of the .posts factor. Candy!

However after listening to CSS Podcast Episode 59, Una and Adam poked at the way forward for container queries: model queries! The present working draft of the CSS Containment Module Degree 3 spec defines container model queries:

A container model question permits querying the computed values of the question container. It’s a boolean mixture of particular person model options (<style-feature>) that every question a single, particular property of the question container.

However no examples on syntax simply but — solely a quick description:

The syntax of a <style-feature> is identical as for a declaration, and its question is true if the computed worth of the given property on the question container matches the given worth (which can also be computed with respect to the question container), unknown if the property or its worth is invalid or unsupported, and false in any other case. The boolean syntax and logic combining model options right into a model question is identical as for CSS characteristic queries. (See @helps.)

So, sure, given time we should always count on to tug off one thing like this:

.posts {
  container-name: posts;
}

@container posts (background-color: #f8a100) {
  /* Change types when `posts` container has an orange background */
  .publish {
    coloration: #fff;
  }
}

That’s a reasonably dumb instance. One factor to notice is that the container-type is not primarily based on the container’s inline-size however by model. We might delcare that like so:

.posts {
  container-name: posts;
  container-type: model; /* pointless */
}

…however all container queries are model queries by default. Properly. at the least because it stands at this time. Miriam Suzanne has a pleasant define of the doable points which may pop up with that.

The place may querying a container’s types come in useful? I don’t know but! However my thoughts gos to a couple locations:

• Customized property values: We’ve seen customized properties used like state indicators, such because the DRY-switching technique Ana coated some time again. The worth adjustments, and so do types.
• Alternate darkish mode method: As a substitute of basing all of it on a physique class change that re-assigns customized property values, possibly we are able to change a whole coloration palette if, say, the physique background adjustments coloration.
• Extra complicated question situations: Like, say, we need to apply types when the dimension and model situations for a container are met.

Una additionally talked about within the CSS Podcast that container model queries might assist forestall some awkward styling conditions, like if we occur to have italicized textual content in an already italicized blockquote:

blockquote {
  container-name: quote;
}

@container quote (font-style: italic) {
  em, i, q, tackle {
    font-style: regular;
  }
}