Is this really the way forward? I'm pretty sure implementing CSS from scratch (just looking at the specs) would take the average developer at least 10,000 hours. But in any case, why doesn't the container query bind to a class? Having to name your container is so weird (we already <i>have</i> names: they're called classes; and IDs; and DOM elements; and pseudo-classes; and aria labels; we need more!?).<p><pre><code> .special-wrapper {
--theme: dark;
container-name: stats;
}
@container stats style(--theme: dark) {
.stat {
/* Add the dark styles. */
}
}
</code></pre>
Not to mention that half the problems in the blog post are completely manufactured:<p>> That works fine, but if there is a space character within the <figcaption> element, it will fail.<p>Uh, yeah, that's how :empty works (it's not "empty"). If that's such a pain point, I'd propose a :no-children-but-maybe-empty pseudo-class before you add a completely new feature to the language, :but-maybe-that's-just-me.<p><pre><code> /* Instead of.. */
html[dir="rtl"] .button-icon {
transform: scaleX(-1);
}
/* We do this */
@container state(dir: rtl) {
.button-icon {
transform: scaleX(-1);
}
}
</code></pre>
Insert "they're exactly the same" meme. (Except for more curly braces: fun.)
Interesting to see this, as I feel like I've seen arguments against this kind of state-based querying come up to avoid cases where you end up with an infinite loop of state query applying -> new styles applying -> new styles undo the state -> state query not applying -> styles removed -> original state query applying, repeat indefinitely. I believe this was the rationale for not having pseudo states for when a container is scrollable, for instance. I wonder what they've done to avoid these cases.<p>For instance, in their `state(wrap: true)` example, now that the wrapping element is hidden, isn't it no longer wrapping? Why does the query continue to apply?
Really cool, seem like it'd make styling responsive pages considerably more easy.<p>It's interesting that CSS has been moving forward at a rapid pace to make extra tooling (LESS, Sass, etc) increasingly unnecessary, but at least from the layman's point of view (web dev isn't my bread and butter), HTML does not seem to be getting nearly as much attention. Clearly there's a need for more capable HTML as evidenced by the countless Rube Goldberg machines built atop it to make it usable, so why isn't there as much interest in developing it?
Is there an IDE out there with really good CSS+HTML intellisense/tools? Not just like suggesting standard properties but actually keeping track of rule usages, refactoring duplicate rules into a single class, jump to related rules (maybe a media/container/state query somewhere else also affects a rule) that sort of thing.<p>It’s confusing enough now that I would actually want some tooling to help.<p>I know that sort of thing really relies on the document that uses the CSS to be parsable somehow, but a lot of JS frameworks are writing templates that just look like HTML or JSX now.
This looks like a very welcome addition, I will certainly be using it if it makes it to standard. I've often had to resort to JS to "detect" when my sticky elements are stuck before.<p>I really like all this invitation that's happing with CSS at the moment, and I do believe it's coming from a place of ambition for the open standards. The standards process seems to be doing a good job of selecting the additions that other browsers have tested and committed to, so it doesn't feel like a "embrace/extend/extinguish" process from the Google Chrome team.<p>I know some people feel these additions are making CSS "too big", but the joy of it is that you can select what subset you want to use. The web platform is a platform for all, and that it what I love about it. You can build anything from a simple text page to a full blown application with one toolkit.
The last case could be covered by the `dir` pseudo-class.<p><pre><code> .button-icon:dir(rtl) {
transform: scaleX(-1);
}
</code></pre>
However, it's not yet supported in Chromium browsers, so for now the attribute selector is as close as you can get.<p><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/:dir" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/CSS/:dir</a>
I like these however why not just use pseudo-selectors instead of a named container?<p><pre><code> #header:stuck {}
#nav:wrapped {}
</code></pre>
I feel like we already have a system for states like this with :hover, :empty etc?<p>Or am I missing something?
So, IMO what is actually cool about this is it will allow you to detect scroll position without JS, which opens up a whole bunch of very nice posibilities!
Oh my god, no. Why is presentational description language being used to _query the very presentational state it’s creating_?<p>This is not at all like media queries or other meta states driven by some higher level operation. This is absolutely the wrong direction.
> The Chromium team is experimenting with a new type of query, which is called State Query<p>Great. They have an army of devs working on something that you can't explain properly.<p>> That’s it for this quick post. What do you think?<p>Front end dev's look for new ways to find work. Impressively so.<p>We already mastered the css, then you came with scss (special, even though it transpiles to css)<p>"They let us query a container based on its width." -<p>UI devs looking for work.<p>Edit : Go into creativity/art whatever<p>You don't see any HTML advocates here.