10 ms·

Future CSS: State Container Queries

231 points by brandrick 3y ago

samwillis 3y ago
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. 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. 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.
- aloisdg 3y ago
  I think we are going to come back to a split of jobs between the front stack. html+css template in one side and a js dev or server side dev in another. They will work together as one but with a different skillset.
- The_Colonel 3y ago
  > 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 browser implementation teams don't get to choose what to support, though. The argument is usually that a too big web platform will lead to a browser monoculture and increased control by one company.
  - inopinatus 3y ago
    Browser implementation teams actually do sometimes refuse to implement a feature of the applicable standards. It's pretty rare, though. The Webkit team's refusal to implement customized built-in elements sticks in the mind, not least because their reasons (and inability to describe an alternative) always sound more like a vendor pissing contest than any kind of engineering discussion.
wouldbecouldbe 3y ago
Yeah that's main thing missing, media queries should have been "relative" to its parent from the start not window absolute.
- agloe_dreams 3y ago
  They added that last year, but I agree. This proposal is around adding a query for other properties on a container.
- bunga-bunga 3y ago
  Width media queries are far older than you think, so it definitely makes sense that they’re relative to the viewport. Firefox was the first to implement them in 2006. At that time “components” were in their fetal stage. https://caniuse.com/mdn-css_at-rules_media_width https://caniuse.com/mdn-css_at-rules_media_width
wbobeirne 3y ago
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. 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?
- kristiandupont 3y ago
  Good point. I think container queries are cool and intuitively useful, much more so than queries based on what the browser window size happens to be. These are not nearly as obvious to me. I get the nav bar scenario, but I think I find the quest for "CSS purity" where any design, no matter how dynamic, can be expressed without Javascript seems a bit silly. I have no problem with it, I just also don't think it's quite as noble as some seem to think.
  - alwillis 3y ago
    > I get the nav bar scenario, but I think I find the quest for "CSS purity" where any design, no matter how dynamic, can be expressed without Javascript seems a bit silly. I have no problem with it, I just also don't think it's quite as noble as some seem to think. I think you're missing the point. Adding functionality to CSS makes is mostly about separation of concerns and making desired features accessible to a wider audience than just JavaScript programmers. And while a good programmer can do a lot with JavaScript, all of the machinery for layout—flex box, grid, container queries—is in CSS, so it makes sense to build on that.
- wokwokwok 3y ago
  Yes, it seems recursive and I don’t like it. You can wave your hands around as much as you like but fundamentally this state based rule stuff says: - apply styles - now, query the current state - based on the current state, apply different styles I understand there are complex interactions that people want to cater for like sticky headers, but… really? There’s only so far you can bandaid a declarative language like css. If you want dynamic behaviour, use javascript. That’s why it exists.
somishere 3y ago
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!
- eyelidlessness 3y ago
  Weirdly enough, with the new scroll-driven animations spec (the spec’s terminology), you can do all sorts of position-based styling without any actual scrolling taking place[1]. Of course you can also use it for its intended purpose of actually detecting scroll position. But this also unlocks a lot of other style query problems, like the cursed wrap detection. For some cases, container queries should also be sufficient. And contrary to many of the other responses here, yes I think this flexibility is important progress. There are tons of fairly straightforward (even trivially specified) layout techniques that are currently next to impossible without some combination of hardcoding measurements and/or JS, which are going to become reasonably achievable in the next year or two. That’s fantastic. And for everyone who complains about this complexity at the styling level, it’ll eventually eliminate the need for a whole class of runtime JS doing a whole bunch of inefficient calculations badly. 1: https://kizu.dev/position-driven-styles/ https://kizu.dev/position-driven-styles/
  - somishere 3y ago
    Thanks for the ref, hadn't heard of this!
kitsunesoba 3y ago
Really cool, seem like it'd make styling responsive pages considerably more easy. 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?
- _jesse 3y ago
  It's not moving as fast as CSS has been, but they have been adding new elements to HTML. <summary> and <details> for accordions, <dialog> for modals, and I've heard murmurs of a <selectmenu> element that does everything <select> does while allowing the developer full control over the look.
  - ughitsaaron 3y ago
    I had no idea about these elements or their APIs. Maybe one downside to living in JSX all the time is that it can encourage ignorance of the foundation it’s built on.
    - jakelazaroff 3y ago
      You can use these within JSX! I use <details> and <summary> all the time. Not so much <dialog> — since there are still accessibility issues by default, I’d rather use a library that wraps it. If and when <selectmenu> drops you can bet I’ll be ditching Radix for the native solution.
      - lelandfe 3y ago
        I've been exploring using dialog for modals - what a11y issues does it have?
        3y ago
deleted 3y ago
[deleted]
miohtama 3y ago
Is CSS Turing complete yet?
- lyvxh 3y ago
  Well, if you consider the accompanying HTML as well as a user mindlessly clicking orange squares as part of the execution, then yes, it is: https://jsfiddle.net/Camilo/eQyBa/ https://jsfiddle.net/Camilo/eQyBa/
  - tetha 3y ago
    I came across that as well, as well as these two interesting blog posts: https://accodeing.com/blog/2015/duty-calls-css3-is-not-proven-to-be-turing-complete https://accodeing.com/blog/2015/duty-calls-css3-is-not-prove... https://accodeing.com/blog/2015/css3-proven-to-be-turing-complete https://accodeing.com/blog/2015/css3-proven-to-be-turing-com... So yeah, it's most likely as powerful as our current computers.
- alwillis 3y ago
  Yes, for a while now.
- OtherShrezzing 3y ago
  There's already a bunch of ways to make "something close to Turing Complete CSS", but there's usually some caveat. This change, when applied with css transition to split commands, would allow you to create loops, and enable you to implement the commands MOV, JMP, INC, and DEC. It should be possible to compile an arbitrary C program with just those commands (some papers have shown just MOV will do). In the most inefficient scenario, you should be able to draw a series of AND/OR and NOT/NAND gates to a HTML document, and colour in different outputs based on their inputs. So CSS should be Turing Complete without caveats after this feature is introduced. I'm not sure what the output of such an application could be. I guess just the satisfaction of knowing that some computation is occurring, if that counts?
  - miohtama 3y ago
incrudible 3y ago
Just give up and add JS to CSS already.
- willio58 3y ago
  I mean, I use JS in CSS daily at work (really CSS in JS). Just not through .css files
cjpearson 3y ago
The last case could be covered by the `dir` pseudo-class. .button-icon:dir(rtl) { transform: scaleX(-1); } However, it's not yet supported in Chromium browsers, so for now the attribute selector is as close as you can get. https://developer.mozilla.org/en-US/docs/Web/CSS/:dir https://developer.mozilla.org/en-US/docs/Web/CSS/:dir
stabbles 3y ago
CSS has a feature creep that makes it harder and harder to write a new browser from scratch
- silverwind 3y ago
  No human is going to write a fully-featured browser from scratch anymore. Maybe AIs will do.
  - arzig 3y ago
    Ladybird sure thinks they are going to. I’m curious how successful they will be.
    - TheMode 3y ago
      Kinda doubt they will achieve parity. Even if they do, for how long? The problem is that the spec is a moving target, you cannot justify maintaining a platform indefinitely while a complete version exist on the side.
      - lbotos 3y ago
        Lets say they get 90% of modern site compatibility, could they dethrone Mozilla? Possibly? I'd consider switching and supporting "the next Mozilla" if they were close. I just got a built in to the browser pop-up add a few weeks ago from Mozilla about a VPN product... sheesh.
        bruce511 3y ago
        Let's separate the -browser- from the -engine- for a moment. Nothing stops a new project (eg Brave) from implementing a new browser based on an existing engine. And you even have 3 big mature engines to choose from (gecko, website and blink). The engine is responsible for the HTML, CSS and JavaScript support, which is the bit everyone seems concerned about re standards. The wrapper around that engine is significant - and where most of the complaints actually seem to lie. Built in popups, tracking, phoning home etc. I'm not sure we need another engine. By contrast there are quite a few browsers to choose from built on those engines. Building a new -browser- is "easy". Building a new engine is "hard" (and would be very expensive to keep current.) Incidentally 90% is likely useless. 99% -might- be enough, depending on which 1% is missing.
quickthrower2 3y ago
If you need to style something when it is stuck, why not make the css class that made it stuck include that style?
- omeletdufromage 3y ago
  > If you need to style something when it is stuck, why not make the css class that made it stuck include that style? Because the CSS rules that define sticky only defines when something gets stuck, not that it's stuck. Ergo, it can say "this element becomes stuck when it's containing element is 200px from the top edge of the viewport", but until the user actually scrolls the document so that's true, the CSS rules that defined that doesn't make it stuck yet. Personally, I'd settle for a pseudo class (e.g. `:stuck`, like `:active` I suppose). Currently I use an `IntersectionObserver` to dynamically toggle a `--stuck` class on my stickies, and I can target that as you describe it.
  - zerocrates 3y ago
    Pseudoclass seems like the obvious answer here but maybe there's a reason that's undesirable that I'm not familiar with.
    - rhdunn 3y ago
      I wonder if the idea is that adding pseudo-classes for the different things is not really scalable because you would ultimately need to do it for a lot of things -- requiring browsers to implement, test, and maintain custom code for each selector -- and you cannot anticipate every website's needs. That would be a better framing for this feature. Given that framing, I can now see how it could be useful for things like custom controls not present in the set provided by the browser. It would be interesting to see if browsers could use this mechanism internally to implement pseudo-classes.
  - quickthrower2 3y ago
    Then part of me feels like CSS shouldn't do the stuck thing at all. That's a job for scripting. There are unlimited behaviours like this you could try to account for declaratively but some JS will do it nicely. The thing about adding this to CSS is you are making CSS more complex with redraw loops as it needs to keep reconfiguring stuff as it gazes into thousands of it's own navels.
graypegg 3y ago
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. It’s confusing enough now that I would actually want some tooling to help. 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.
- DaiPlusPlus 3y ago
  What you're asking for simply isn't possible (at least in the general case) because of two reasons: 1. A CSS stylesheet cannot be interpreted without a corresponding document (HTML, usually) with which to test CSS selector rules against. 2. Excepting static sites, HTML is generated dynamically, which means (thanks to our old friend, The Halting Problem) impossible (in the general case) for tooling to use static-analysis-based approaches for CSS linting when given even a basic document-outline or structure for, for example, a React/JSX application. (CSS static-analysis also got 100x harder when the `:has()` selector was introduced, because it invalidates a number of optimizations possible due to CSS's original (and strict) "forward-only" design (i.e. before `:has()`, CSS selectors could only match elements based on their ancestors or previous-siblings: never their descendants or next-siblings, which also meant that selectors didn't need to be re-evaluated as the document's HTML was still being loaded) ----- Existing tooling does what-it-can, for example, I've been often surprised at how well Visual Studio (not VS Code)'s HTML/Razor editor can make very reasonable CSS class suggestions when typing-out HTML - and while there's often good stuff in the Node/npm ecosystem, especially for typical frontend dev scenarios, like building SASS/LESS in a Grunt build), a common problem I've run into is the tooling breaking completely whenever I want to use an ultramodern CSS feature, especially those that introduce a new syntax - YMMV, of course.
- chabad360 3y ago
  Jetbrains IntelliJ does a pretty good job for me. It's not perfect by any means (esp. because I'm working with go templates, and it doesn't fully understand those), but it gets the job done better than anything else I've used.
dvt 3y ago
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 have names: they're called classes; and IDs; and DOM elements; and pseudo-classes; and aria labels; we need more!?). .special-wrapper { --theme: dark; container-name: stats; } @container stats style(--theme: dark) { .stat { /* Add the dark styles. */ } } Not to mention that half the problems in the blog post are completely manufactured: > That works fine, but if there is a space character within the <figcaption> element, it will fail. 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. /* Instead of.. */ html[dir="rtl"] .button-icon { transform: scaleX(-1); } /* We do this */ @container state(dir: rtl) { .button-icon { transform: scaleX(-1); } } Insert "they're exactly the same" meme. (Except for more curly braces: fun.)
- silverwind 3y ago
  > why doesn't the container query bind to a class Agree, a `@container <complex-selector-list> <container-condition> {}` would be so much more ergonomic.
- OJFord 3y ago
  > implementing CSS from scratch (just looking at the specs) would take the average developer at least 10,000 hours. You're way too generous: the average developer couldn't do it.
  - pier25 3y ago
    Or maybe they could but with terrible performance.
- tambourine_man 3y ago
  I had the same feeling reading the article. This is getting out of hand. No radical new way of doing things, just more ways of doing the same things.
dclowd9901 3y ago
Oh my god, no. Why is presentational description language being used to _query the very presentational state it’s creating_? This is not at all like media queries or other meta states driven by some higher level operation. This is absolutely the wrong direction.
- eyelidlessness 3y ago
  It’s exactly like media queries, just not attached to a global root which can’t convey any information except what the browser specifically decides to index for querying purposes.
  - dclowd9901 3y ago
    Since when did CSS control window size?
    - eyelidlessness 3y ago
      I don’t understand the point of the question. Since when did .foo control the size of :scope .foo? To the extent it does, since when did a descendant of :root not influence the size of :root?
deleted 3y ago
[deleted]
bilekas 3y ago
> The Chromium team is experimenting with a new type of query, which is called State Query Great. They have an army of devs working on something that you can't explain properly. > That’s it for this quick post. What do you think? Front end dev's look for new ways to find work. Impressively so. We already mastered the css, then you came with scss (special, even though it transpiles to css) "They let us query a container based on its width." - UI devs looking for work. Edit : Go into creativity/art whatever You don't see any HTML advocates here.
Reptur 3y ago
Can we not over-complicate CSS? Innovation is supposed to be _easier_ not more complicated.
sachahjkl 3y ago
the wrap detection for flex elements would be really nice to have. Kind of mind boggling that it's not already in the spec.
Liquidor 3y ago
I like these however why not just use pseudo-selectors instead of a named container? #header:stuck {} #nav:wrapped {} I feel like we already have a system for states like this with :hover, :empty etc? Or am I missing something?
idk1 3y ago
Cool! Where can I find a list of all `container-type`s and their equivalent states? It looks like there's so many.
Alifatisk 3y ago
This blog has some other tasty stuff like ishadeed.com/article/comment-component
progx 3y ago
You might as well add if, then, else, functions, do, while, switch, ...
- t0astbread 3y ago
  All of that? That's so complicated. Maybe we can add something more versatile. Something like: .my-button { padding: 1em; goto: my-button-colors; } html { label: my-button-colors; background: white; color: black; } @media (prefers-color-scheme: dark) { html { label: my-button-colors; background: black; color: white; } } The most specific label will be jumped to. Labels follow the usual specificity rules (also including `!important`). Jumps to an invalid label are no-ops. Styles within a ruleset are evaluated top-to-bottom. Labels propagate to children. Of course the above example is silly. We also need to make sure we don't apply button styles to the `html` element. We can do that with a protective conditional goto using custom properties (aka variables). We can also make use of variables to implement returns: .my-button { --end: none; --next: my-button-colors; label: return; goto: var(--next); padding: 1em; } html { --end: end; label: end; /* Jump here to end a ruleset immediately. */ } html { label: my-button-colors; goto: var(--end); background: white; color: black; --next: none; goto: return; } @media (prefers-color-scheme: dark) { html { label: my-button-colors; goto: var(--end); background: black; color: white; --next: none; goto: return; } }
T3RMINATED 3y ago
[dead]

231 points by brandrick 3y ago

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. 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. 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.

aloisdg 3y ago
I think we are going to come back to a split of jobs between the front stack. html+css template in one side and a js dev or server side dev in another. They will work together as one but with a different skillset.
The_Colonel 3y ago
> 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 browser implementation teams don't get to choose what to support, though. The argument is usually that a too big web platform will lead to a browser monoculture and increased control by one company.
- inopinatus 3y ago
  Browser implementation teams actually do sometimes refuse to implement a feature of the applicable standards. It's pretty rare, though. The Webkit team's refusal to implement customized built-in elements sticks in the mind, not least because their reasons (and inability to describe an alternative) always sound more like a vendor pissing contest than any kind of engineering discussion.

wouldbecouldbe 3y ago

Yeah that's main thing missing, media queries should have been "relative" to its parent from the start not window absolute.

agloe_dreams 3y ago
They added that last year, but I agree. This proposal is around adding a query for other properties on a container.
bunga-bunga 3y ago
Width media queries are far older than you think, so it definitely makes sense that they’re relative to the viewport. Firefox was the first to implement them in 2006. At that time “components” were in their fetal stage. https://caniuse.com/mdn-css_at-rules_media_width https://caniuse.com/mdn-css_at-rules_media_width

wbobeirne 3y ago

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. 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?

kristiandupont 3y ago
Good point. I think container queries are cool and intuitively useful, much more so than queries based on what the browser window size happens to be. These are not nearly as obvious to me. I get the nav bar scenario, but I think I find the quest for "CSS purity" where any design, no matter how dynamic, can be expressed without Javascript seems a bit silly. I have no problem with it, I just also don't think it's quite as noble as some seem to think.
- alwillis 3y ago
  > I get the nav bar scenario, but I think I find the quest for "CSS purity" where any design, no matter how dynamic, can be expressed without Javascript seems a bit silly. I have no problem with it, I just also don't think it's quite as noble as some seem to think. I think you're missing the point. Adding functionality to CSS makes is mostly about separation of concerns and making desired features accessible to a wider audience than just JavaScript programmers. And while a good programmer can do a lot with JavaScript, all of the machinery for layout—flex box, grid, container queries—is in CSS, so it makes sense to build on that.
wokwokwok 3y ago
Yes, it seems recursive and I don’t like it. You can wave your hands around as much as you like but fundamentally this state based rule stuff says: - apply styles - now, query the current state - based on the current state, apply different styles I understand there are complex interactions that people want to cater for like sticky headers, but… really? There’s only so far you can bandaid a declarative language like css. If you want dynamic behaviour, use javascript. That’s why it exists.

somishere 3y ago

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!

eyelidlessness 3y ago
Weirdly enough, with the new scroll-driven animations spec (the spec’s terminology), you can do all sorts of position-based styling without any actual scrolling taking place[1]. Of course you can also use it for its intended purpose of actually detecting scroll position. But this also unlocks a lot of other style query problems, like the cursed wrap detection. For some cases, container queries should also be sufficient. And contrary to many of the other responses here, yes I think this flexibility is important progress. There are tons of fairly straightforward (even trivially specified) layout techniques that are currently next to impossible without some combination of hardcoding measurements and/or JS, which are going to become reasonably achievable in the next year or two. That’s fantastic. And for everyone who complains about this complexity at the styling level, it’ll eventually eliminate the need for a whole class of runtime JS doing a whole bunch of inefficient calculations badly. 1: https://kizu.dev/position-driven-styles/ https://kizu.dev/position-driven-styles/
- somishere 3y ago
  Thanks for the ref, hadn't heard of this!

kitsunesoba 3y ago

Really cool, seem like it'd make styling responsive pages considerably more easy. 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?

_jesse 3y ago
It's not moving as fast as CSS has been, but they have been adding new elements to HTML. <summary> and <details> for accordions, <dialog> for modals, and I've heard murmurs of a <selectmenu> element that does everything <select> does while allowing the developer full control over the look.
- ughitsaaron 3y ago
  I had no idea about these elements or their APIs. Maybe one downside to living in JSX all the time is that it can encourage ignorance of the foundation it’s built on.
  - jakelazaroff 3y ago
    You can use these within JSX! I use <details> and <summary> all the time. Not so much <dialog> — since there are still accessibility issues by default, I’d rather use a library that wraps it. If and when <selectmenu> drops you can bet I’ll be ditching Radix for the native solution.
    - lelandfe 3y ago
      I've been exploring using dialog for modals - what a11y issues does it have?
      - 3y ago

deleted 3y ago

[deleted]

miohtama 3y ago

Is CSS Turing complete yet?

lyvxh 3y ago
Well, if you consider the accompanying HTML as well as a user mindlessly clicking orange squares as part of the execution, then yes, it is: https://jsfiddle.net/Camilo/eQyBa/ https://jsfiddle.net/Camilo/eQyBa/
- tetha 3y ago
  I came across that as well, as well as these two interesting blog posts: https://accodeing.com/blog/2015/duty-calls-css3-is-not-proven-to-be-turing-complete https://accodeing.com/blog/2015/duty-calls-css3-is-not-prove... https://accodeing.com/blog/2015/css3-proven-to-be-turing-complete https://accodeing.com/blog/2015/css3-proven-to-be-turing-com... So yeah, it's most likely as powerful as our current computers.
alwillis 3y ago
Yes, for a while now.
OtherShrezzing 3y ago
There's already a bunch of ways to make "something close to Turing Complete CSS", but there's usually some caveat. This change, when applied with css transition to split commands, would allow you to create loops, and enable you to implement the commands MOV, JMP, INC, and DEC. It should be possible to compile an arbitrary C program with just those commands (some papers have shown just MOV will do). In the most inefficient scenario, you should be able to draw a series of AND/OR and NOT/NAND gates to a HTML document, and colour in different outputs based on their inputs. So CSS should be Turing Complete without caveats after this feature is introduced. I'm not sure what the output of such an application could be. I guess just the satisfaction of knowing that some computation is occurring, if that counts?
- miohtama 3y ago

incrudible 3y ago

Just give up and add JS to CSS already.

willio58 3y ago
I mean, I use JS in CSS daily at work (really CSS in JS). Just not through .css files

cjpearson 3y ago

The last case could be covered by the `dir` pseudo-class. .button-icon:dir(rtl) { transform: scaleX(-1); } However, it's not yet supported in Chromium browsers, so for now the attribute selector is as close as you can get. https://developer.mozilla.org/en-US/docs/Web/CSS/:dir https://developer.mozilla.org/en-US/docs/Web/CSS/:dir

stabbles 3y ago

CSS has a feature creep that makes it harder and harder to write a new browser from scratch

silverwind 3y ago
No human is going to write a fully-featured browser from scratch anymore. Maybe AIs will do.
- arzig 3y ago
  Ladybird sure thinks they are going to. I’m curious how successful they will be.
  - TheMode 3y ago
    Kinda doubt they will achieve parity. Even if they do, for how long? The problem is that the spec is a moving target, you cannot justify maintaining a platform indefinitely while a complete version exist on the side.
    - lbotos 3y ago
      Lets say they get 90% of modern site compatibility, could they dethrone Mozilla? Possibly? I'd consider switching and supporting "the next Mozilla" if they were close. I just got a built in to the browser pop-up add a few weeks ago from Mozilla about a VPN product... sheesh.
      - bruce511 3y ago
        Let's separate the -browser- from the -engine- for a moment. Nothing stops a new project (eg Brave) from implementing a new browser based on an existing engine. And you even have 3 big mature engines to choose from (gecko, website and blink). The engine is responsible for the HTML, CSS and JavaScript support, which is the bit everyone seems concerned about re standards. The wrapper around that engine is significant - and where most of the complaints actually seem to lie. Built in popups, tracking, phoning home etc. I'm not sure we need another engine. By contrast there are quite a few browsers to choose from built on those engines. Building a new -browser- is "easy". Building a new engine is "hard" (and would be very expensive to keep current.) Incidentally 90% is likely useless. 99% -might- be enough, depending on which 1% is missing.

quickthrower2 3y ago

If you need to style something when it is stuck, why not make the css class that made it stuck include that style?

omeletdufromage 3y ago
> If you need to style something when it is stuck, why not make the css class that made it stuck include that style? Because the CSS rules that define sticky only defines when something gets stuck, not that it's stuck. Ergo, it can say "this element becomes stuck when it's containing element is 200px from the top edge of the viewport", but until the user actually scrolls the document so that's true, the CSS rules that defined that doesn't make it stuck yet. Personally, I'd settle for a pseudo class (e.g. `:stuck`, like `:active` I suppose). Currently I use an `IntersectionObserver` to dynamically toggle a `--stuck` class on my stickies, and I can target that as you describe it.
- zerocrates 3y ago
  Pseudoclass seems like the obvious answer here but maybe there's a reason that's undesirable that I'm not familiar with.
  - rhdunn 3y ago
    I wonder if the idea is that adding pseudo-classes for the different things is not really scalable because you would ultimately need to do it for a lot of things -- requiring browsers to implement, test, and maintain custom code for each selector -- and you cannot anticipate every website's needs. That would be a better framing for this feature. Given that framing, I can now see how it could be useful for things like custom controls not present in the set provided by the browser. It would be interesting to see if browsers could use this mechanism internally to implement pseudo-classes.
- quickthrower2 3y ago
  Then part of me feels like CSS shouldn't do the stuck thing at all. That's a job for scripting. There are unlimited behaviours like this you could try to account for declaratively but some JS will do it nicely. The thing about adding this to CSS is you are making CSS more complex with redraw loops as it needs to keep reconfiguring stuff as it gazes into thousands of it's own navels.

graypegg 3y ago

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. It’s confusing enough now that I would actually want some tooling to help. 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.

DaiPlusPlus 3y ago
What you're asking for simply isn't possible (at least in the general case) because of two reasons: 1. A CSS stylesheet cannot be interpreted without a corresponding document (HTML, usually) with which to test CSS selector rules against. 2. Excepting static sites, HTML is generated dynamically, which means (thanks to our old friend, The Halting Problem) impossible (in the general case) for tooling to use static-analysis-based approaches for CSS linting when given even a basic document-outline or structure for, for example, a React/JSX application. (CSS static-analysis also got 100x harder when the `:has()` selector was introduced, because it invalidates a number of optimizations possible due to CSS's original (and strict) "forward-only" design (i.e. before `:has()`, CSS selectors could only match elements based on their ancestors or previous-siblings: never their descendants or next-siblings, which also meant that selectors didn't need to be re-evaluated as the document's HTML was still being loaded) ----- Existing tooling does what-it-can, for example, I've been often surprised at how well Visual Studio (not VS Code)'s HTML/Razor editor can make very reasonable CSS class suggestions when typing-out HTML - and while there's often good stuff in the Node/npm ecosystem, especially for typical frontend dev scenarios, like building SASS/LESS in a Grunt build), a common problem I've run into is the tooling breaking completely whenever I want to use an ultramodern CSS feature, especially those that introduce a new syntax - YMMV, of course.
chabad360 3y ago
Jetbrains IntelliJ does a pretty good job for me. It's not perfect by any means (esp. because I'm working with go templates, and it doesn't fully understand those), but it gets the job done better than anything else I've used.

dvt 3y ago

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 have names: they're called classes; and IDs; and DOM elements; and pseudo-classes; and aria labels; we need more!?). .special-wrapper { --theme: dark; container-name: stats; } @container stats style(--theme: dark) { .stat { /* Add the dark styles. */ } } Not to mention that half the problems in the blog post are completely manufactured: > That works fine, but if there is a space character within the <figcaption> element, it will fail. 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. /* Instead of.. */ html[dir="rtl"] .button-icon { transform: scaleX(-1); } /* We do this */ @container state(dir: rtl) { .button-icon { transform: scaleX(-1); } } Insert "they're exactly the same" meme. (Except for more curly braces: fun.)

silverwind 3y ago
> why doesn't the container query bind to a class Agree, a `@container <complex-selector-list> <container-condition> {}` would be so much more ergonomic.
OJFord 3y ago
> implementing CSS from scratch (just looking at the specs) would take the average developer at least 10,000 hours. You're way too generous: the average developer couldn't do it.
- pier25 3y ago
  Or maybe they could but with terrible performance.
tambourine_man 3y ago
I had the same feeling reading the article. This is getting out of hand. No radical new way of doing things, just more ways of doing the same things.

dclowd9901 3y ago

Oh my god, no. Why is presentational description language being used to _query the very presentational state it’s creating_? This is not at all like media queries or other meta states driven by some higher level operation. This is absolutely the wrong direction.

eyelidlessness 3y ago
It’s exactly like media queries, just not attached to a global root which can’t convey any information except what the browser specifically decides to index for querying purposes.
- dclowd9901 3y ago
  Since when did CSS control window size?
  - eyelidlessness 3y ago
    I don’t understand the point of the question. Since when did .foo control the size of :scope .foo? To the extent it does, since when did a descendant of :root not influence the size of :root?

deleted 3y ago

[deleted]

bilekas 3y ago

> The Chromium team is experimenting with a new type of query, which is called State Query Great. They have an army of devs working on something that you can't explain properly. > That’s it for this quick post. What do you think? Front end dev's look for new ways to find work. Impressively so. We already mastered the css, then you came with scss (special, even though it transpiles to css) "They let us query a container based on its width." - UI devs looking for work. Edit : Go into creativity/art whatever You don't see any HTML advocates here.

Reptur 3y ago

Can we not over-complicate CSS? Innovation is supposed to be _easier_ not more complicated.

sachahjkl 3y ago

the wrap detection for flex elements would be really nice to have. Kind of mind boggling that it's not already in the spec.

Liquidor 3y ago

I like these however why not just use pseudo-selectors instead of a named container? #header:stuck {} #nav:wrapped {} I feel like we already have a system for states like this with :hover, :empty etc? Or am I missing something?

idk1 3y ago

Cool! Where can I find a list of all `container-type`s and their equivalent states? It looks like there's so many.

Alifatisk 3y ago

This blog has some other tasty stuff like ishadeed.com/article/comment-component

progx 3y ago

You might as well add if, then, else, functions, do, while, switch, ...

t0astbread 3y ago
All of that? That's so complicated. Maybe we can add something more versatile. Something like: .my-button { padding: 1em; goto: my-button-colors; } html { label: my-button-colors; background: white; color: black; } @media (prefers-color-scheme: dark) { html { label: my-button-colors; background: black; color: white; } } The most specific label will be jumped to. Labels follow the usual specificity rules (also including `!important`). Jumps to an invalid label are no-ops. Styles within a ruleset are evaluated top-to-bottom. Labels propagate to children. Of course the above example is silly. We also need to make sure we don't apply button styles to the `html` element. We can do that with a protective conditional goto using custom properties (aka variables). We can also make use of variables to implement returns: .my-button { --end: none; --next: my-button-colors; label: return; goto: var(--next); padding: 1em; } html { --end: end; label: end; /* Jump here to end a ruleset immediately. */ } html { label: my-button-colors; goto: var(--end); background: white; color: black; --next: none; goto: return; } @media (prefers-color-scheme: dark) { html { label: my-button-colors; goto: var(--end); background: black; color: white; --next: none; goto: return; } }

T3RMINATED 3y ago

[dead]