[HN Gopher] Future CSS: State Container Queries
___________________________________________________________________
Future CSS: State Container Queries
Author : brandrick
Score : 140 points
Date : 2023-06-28 18:46 UTC (4 hours ago)
(HTM) web link (ishadeed.com)
(TXT) w3m dump (ishadeed.com)
| incrudible wrote:
| Just give up and add JS to CSS already.
| kitsunesoba wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bobthepanda wrote:
| What would you suggest, that is compatible with its goal of
| being a markup language?
|
| A lot of the machines built on top of HTML (e.g. JSX) add non-
| markup to HTML so you can handle if-else/filter and loop. But I
| don't think there's ever been interest in expressing that
| natively in HTML itself.
| kitsunesoba wrote:
| The main thing that feels like it could use work is the lack
| of adequately capable primitives/widgets. Many are plain
| missing while others are too basic/limited.
| cjpearson wrote:
| 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
| [deleted]
| quickthrower2 wrote:
| If you need to style something when it is stuck, why not make the
| css class that made it stuck include that style?
| stabbles wrote:
| CSS has a feature creep that makes it harder and harder to write
| a new browser from scratch
| silverwind wrote:
| No human is going to write a fully-featured browser from
| scratch anymore. Maybe AIs will do.
| [deleted]
| graypegg wrote:
| 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.
| samwillis wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| wouldbecouldbe wrote:
| Yeah that's main thing missing, media queries should have been
| "relative" to its parent from the start not window absolute.
| bunga-bunga wrote:
| 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
| agloe_dreams wrote:
| They added that last year, but I agree.
|
| This proposal is around adding a query for other properties on
| a container.
| dvt wrote:
| 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 wrote:
| > 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 wrote:
| > 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_.
| dclowd9901 wrote:
| 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.
| wbobeirne wrote:
| 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 wrote:
| 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.
| somishere wrote:
| 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!
| miohtama wrote:
| Is CSS Turing complete yet?
| alwillis wrote:
| Yes, for a while now.
| lyvxh wrote:
| 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/
| tetha wrote:
| I came across that as well, as well as these two interesting
| blog posts:
|
| https://accodeing.com/blog/2015/duty-calls-css3-is-not-
| prove...
|
| https://accodeing.com/blog/2015/css3-proven-to-be-turing-
| com...
|
| So yeah, it's most likely as powerful as our current
| computers.
| OtherShrezzing wrote:
| 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?
___________________________________________________________________
(page generated 2023-06-28 23:00 UTC)