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!?).
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.)
All of the CSS grid syntax craziness is one of the biggest reasons I was completely OK when our dev team adopted Tailwind. I am one of those devs who couldn't implement all of the CSS spec like @OJFord mentioned... but probably because I always forget what in the world all the options mean/are, haha!
> but probably because I always forget what in the world all the options mean/are, haha!
CSS is so big, and only getting bigger all the time (just read the Chrome release highlights over the last few years, your head is going to spin just from the CSS additions alone), yet at the same time it's not a language (where you can typically get by with just learning the basics and start to write useful stuff real fast by relying on general algorithmization skill and programmer intuition), just a massive set of directives you can combine together, I really feel like at the point where it is all in your head and ready to go (i.e. you know what you're about to do, you do it and it does what you intended... without you having to go through a 10 minute Chrome dev tools & Stack Overflow intermezzo), you have to have such a good memory, that you would do much better as a lawyer or a doctor than "mastering css".
Is there some better universal styling solution than CSS? Probably not. Is CSS way, way too big nowadays? Hell yes.
I disagree. While you can absolutely just pick and choose when using css as "salt & pepper" for an internal app ("admin" kind of part of a system), once you get into coding for a reasonably big frontend (of, say, an ecommerce site), suddenly you need all the bells and whistles for all the different media query versions of the site, mobile first is now a real requirement (most ecommerce visits are from mobile platforms and google uses mobile view to index and rate your site with Web Vitals) and so you have to know about flex, grid, typography, sizing, animations, scrolling, interactions, layout shifts, performance, browser support etc. etc. as otherwise you have an ugly, buggy, jumpy, unmaintainable mess on your hands.
There's a reason there are dedicated jobs for just front end development. It's a big task, and often for a different (not worse, just different) kind of person than your typical programmer who enjoys algorithmization. It's more about a person's crisp memory and good visual design ability.
For some of us who work as "full stack" devs sometimes, it's a lot of additional crap that you need to know... and so I can see why things like Tailwind (and its paid and free components) are popular.
As someone who started when CSS was so underpowered that layout was still done with <table>… I remember the introduction of every new CSS feature, and I will cherish them all forever.
The introduction of flexbox was like Christmas to me, and CSS grid was all my birthdays and Christmases at once.
It’s definitely much easier when you learn all of these features as a drip drip drip over decades.
I can’t imagine picking up CSS from scratch as a new dev in 2023. It must be extremely intimidating.
Although on balance, I’d say that despite the extra features, CSS is a lot simpler now than it was in the 00s and early 10s. The rendering engines are much better and agree almost all the time, in the past you’d spend a most of your time debugging your layout in different browsers, or fighting CSS to get it to get it to make the layout that you want (and eventually giving up and using a table)
I don’t disagree with you. But you also don’t disagree with me either.
You said it yourself “once you get into the coding for a reasonably big frontend”. That’s a specific task and the web is not made of only big projects.
CSS is vast but also allows you to ease into it. You don’t have to master it from day one in order to use it.
And that’s the beauty of it imo. I personally enjoy working with CSS and one of the reasons why I like it it’s because after 10 years and hundreds of sites coded I still learn new things about it.
I feel like the frontend gets an unfair treatment by many here on HN. I doubt people complain that the standard library of python is too vast, and you cannot master it. I feel like there is a lack of respect for professionalism on the front end stack and a lack of understanding that we front end developers actually spend a lot of time mastering this craft so we can use it skillfully at our jobs.
The only way I can make sense of this sentiment is that people feel like CSS is something to hack with, it is a toy, for hackers to play with, not a tool for professionals who spend years mastering the skill. I wonder why this is.
My sense of this (and I might be entirely wrong) is that CSS is a tool that is geared towards the presentation/design layer and that is somewhat removed from what most developers do or want to do or are happy doing.
It lives in this weird in between land where it's not really a programming language but it's complex enough to be hard to use by designers who are not really into programming.
I agree with you that mastering frontend requires a lot of time and practice, especially because it's a constantly moving target with new features, new tools and browsers that are constantly evolving.
I personally like it, I love the flexibility and I love that it's constantly changing and I have new tools I can use. It's also funny how there seems to be always something missing.
This may be the case. While it is a standard practice in print design and graphic design that designers learn and use some tools to materialize these design into somewhat of a final product (tools like indesign, illustrator, etc.) it is not a common practice among web designers. A web designer is more likely to create a mock-up in a tool like figma, which a web developer than materialized into HTML, CSS and JavaScript. Of course there is an overlap, where a designer actually writes their own frontend or a web developer does their own design, but most of the industry has a separation there which is not present many other creative industries.
Perhaps there is a lack of understanding of the interaction between a web-developer and a web-designer which creates this unique negative perception of CSS as a tool. A back end developer might simply not understand it.
Isn't the critique that CSS is not at the right level? It's a collection of very specific pragmatic APIs? At least during the big Houdini effort it seemed like browser vendors want to offer something lower level, that allows more and better control of the whole layout and rendering pipeline. Please correct and extend my comment if possible, because I'm admittedly now up to date with even the status of that aforementioned project.
But once you get into a pre-existing project, you have to be aware how every part of the language interact with each other. Grid vs Flex vs Tables vs Queries vs Components You have to know the language pretty well to avoid visual glitches.
Corner and general cases are usually documented on the MDN, but they're not very intuitive, and often very, very subtle. Did you know that just by using an apple magic mouse vs a magic trackpad you could change the behavior of the "overflow" property?
This is a fair point and one I’d agree with when it comes to working on pre-existing projects.
I was commenting on CSS in general. That said, CSS is easy to understand in general IMO so even if you’re not familiar with a specific property or tool within CSS it shouldn’t take a ton of time to understand how to use it.
But that’s my experience with it and I understand that I worked with CSS daily for the past 10+ years so I might have a skewed perspective.
How would you have done differently in the grid spec?
You don't have to use named grid areas if you don't like. But honestly, why wouldn't you. grid-template-areas makes working with grid a walk in the park imo.
Also very few of us web devs know all of CSS by heart. We use tools and reference manuals all the time as we are working. I suspect no python developer knows all of python either and are constantly looking at documentation or hints from their language server/IDE. The real skill is knowing where to look, not what to write.
Just want to preface this with this is all my opinion, and I know I'm not necessarily correct at all.
If I were given free reign, I would have tried to do some different naming for properties like grid-auto-rows/grid-auto-columns/grid-auto-flow. My internal way of thinking about how the first two control the height & width, respectively, don't line up with how I view the word "auto" in other places in CSS.
I also feel like there should have been a true shorthand for just creating an mxn grid. That's one of the biggest reasons I enjoy Tailwind because I can just say "grid grid-cols-3" and get a 3 column grid without me having to explicitly say I want them all even. I would have probably been naïve and made it work closer to the old column-count where giving it a unitless number and it makes it equal in the space; on top of that, I'd then layer the actual spec so you could do variable sized rows/columns.
The other thing I would have done would have been to focus time and effort on finding a way to easily reverse a grid. I know you can use the rtl/ltr hack to do it, and that grid being a 2-axis display method brings a lot of hard questions about "what does reversing a grid mean?". I know names could help here, but it just doesn't make sense in a CMS environment where editors can place as many or as few items in a grid as they want, so I can't just do "a b" -> "b a" based on media query, because there could be columns C through F, too, and I want them all reversed. Thankfully, this is mostly a mobile problem when they're stacked, so I can just switch to flexbox and column reverse, but still would've been nice to have an easier way to do this as the amount of SO posts I remember seeing for this indicated to me that folks did want this feature.
To answer why I don't use grid-template-areas often, I just don't find myself in a lot of situations where naming has made it easier. I guess I could do this kind of thing, but then everyone else is going to ask "where does a/b/c come from?", haha.
Seems like you are looking for grid-template-columns: repeat(3, 1fr). I honestly don’t see a problem with the 1fr part here. I don’t know what you mean with variable sized rows/columns, because you can already do something like:
grid-template-rows: auto var(--some-length) fit-content(30ch) minmax(12ch, auto) 1fr;
While I admit reversing the flow of grid items is a bit more verbose than flex items, it is still a pretty trivial thing to do, if you have named areas, you simply change the order of the area names, if you have explicit columns/rows you can just use negative indices for your grid-column/grid-row. If you have implicit columns/rows, you should probably be using flex (as—unlike grid—flex-direction: row-reverse also adjusts the scroll position) and a subgrid (though I will admit, grid-auto-flow: row-reverse should probably be an option; perhaps you can raise that with the CSSWG if you have a clear use case).
I can see the appeal of Tailwind for developers that don’t feel like becoming experts in CSS layout. However a lot of us frontend devs have spent quite some time studying CSS layout and do know how to work with it to get a desired layout. In my opinion, CSS grid is a resounding success story. I use it all the time in my job without any major issues. Did it take time to learn? Yes it did, I even ordered a whole book on the subject as I was studying it (https://abookapart.com/products/the-new-css-layout). Me personally, I would get insulted if my team decided to go with tailwind, as I would feel left out from my area of expertise. And that now instead of using what I know about CSS, I’m forced to learn a whole new system, and consult new documentation that I’m not familiar with.
It isn't necessarily a "problem", but I personally am a fan of keeping simple use cases as simple as possible. In my eyes, bringing the syntax to barebones makes it easier to read and more maintainable for these ultra simple use cases (for instance this 3x3 equally sized grid).
grid-rows: 3;
grid-columns: 3;
Is it an excruciating pain to need to currently type repeat(3, 1fr)? Nope, not at all, and I'd gladly do it if my team wanted to plain CSS or SASS, but to me that statement doesn't feel nearly as succinct or (dare I say) elegant as other areas of CSS, such as:
margin: 2rem;
padding: 1rem 0.5rem;
What I meant by variable sized rows & columns was to keep the rest of the spec as close as possible to what it is now, but layered on top of my suggested simpler syntax from above. That way if I wanted to do something that isn't just n equal-sized columns, I could just write out
grid-template-columns: 1fr 2fr 1fr;
and it would work as CSS grid currently does. It's the best of both worlds!
I'm also a frontend developer who has spent a pretty significant chunk of time studying CSS. Maybe I gave off the impression that I'm too incompetent to learn the latest features of the language and write them in plain CSS, but that wasn't what I meant. It is way more that I find little pleasure in writing CSS compared to other frontend responsibilities.
Am I happy and grateful that grid, container queries, and the rest of the new features exist? Yes, I am, and grid is one of the tools I reach for the most. In the end, I only had tiny things I wish could have been different about it after using it and realizing "rats, that syntax could have been made a tiny bit simpler for how I use it a lot of the time," or wishes for features that would just make life easier even if the current way of doing things is trivial.
Haha, you know what they say, different strokes for different folks! I didn't feel insulted in the slightest when our lead frontend developer suggested we give Tailwind a trial run. As a group, we were searching for a way to have consistency and a friendlier developer experience[0] throughout our many different projects & internal tools, but without having to bike shed with 10 different frontend developers or saddle someone with the responsibility of adding new CSS helpers as features rolled out (and the inevitable bike shedding that would happen every time). Some of my coworkers were upset about it because they prefer CSS and styling over JS and other frontend bits, but I think even the most fervent "vanilla CSS/SASS or nothing" holdout came around when she had to cover a project while someone was on vacation, and she found a level of consistency and naming that hadn't existed in our codebases.
--
[0] A couple of very old projects in a siloed team had a CSS guru building his own framework in SASS, but it's utility left a lot to be desired. In my opinion, you can't even place all of the blame on him, because his project was extremely standalone (and therefore had lulls when waiting for approvals and this was a way to pass the time and learn) and the company had very little guard rails to prevent this sort of thing. The combination of a small development team splintered between many different projects (no guidelines stating "this is how we are going to do this as a group" existed), everyone being overworked and burned out, and larger projects "winning" eyes of senior developers who held them to higher standards left him in a spot where I think he believed wholeheartedly that he was making a maintainable masterpiece that would end up being used in the rest of the projects when he finally finished it. Sadly, the framework never reached anything resembling a production-ready v1.0, but it did showcase some of his impressive knowledge of CSS.
"Is this really the way forward?" No. The way forward for scale-free systems which implement a hierarchy of competence is to have "the factory smaller than the product" [1]. Instead of the Chrome Canary team and the various Working Groups dictating from above what passes as valid, let the rules be sent at the same time with the interpretation of the rules [2]. In the same manner DNA encodes proteins with no mention of the underlying morphology, but once the RNA starts building the morphology arises.
[2] Not even such a new idea, "Building a Better Web Browser - James Mickens - Harvard CS Colloquium 2015", on rendering at 04:20, https://www.youtube.com/watch?v=1uflg7LDmzI
I've been thinking about this lately: Writing a rendering engine for WASM or something, which then draws to a canvas.
The rendering engine can then be shipped along with the actual UI.
Sure, the rendering engine will take some time to load. However, compiling styling etc. to WebGL instructions at build time might also speed things up considerably.
(The actual reason, however, I'd be interested in this is not performance but improving upon the developer experience and replacing CSS with something better.)
To keep in mind, à la longue, the best CSS is probably no CSS. Does a user really need all these buttons and dropdowns, modals and scrollable containers, or do they need only an input and a container rendering a few paragraphs, an image, a video/audio, possibly a 3D model.
I see no problem if instead of using all these web sites/applications with such a plethora of visual and experience spam, I just have a single input box connected to an agent through which I interact with them all, letting the APIs settle in the background.
Furthermore, concepts such as file systems, operating systems, networking protocols, and so on, are probably terrible abstractions, just the fact that a 10 year old printer is pretty much unusable with a "modern" operating system or that a VFD shipped yesterday from the factory can be rendered useless due to a single byte error in the Modbus connection ought to give second thoughts to anyone daring to call themselves an engineer.
> Insert "they're exactly the same" meme. (Except for more curly braces: fun.)
But the dir can also be auto (especially on inline/quoted content, forms, or multi-language sites), so the browser decides what the dir state is. The example in the article could perhaps be clearer, so I think it's normal for one to think they are the same.
Especially when you only have the container (perhaps you are designing a component library), reacting to state is much more secure, even though the browser support will haunt this feature for at least a year, or a couple of years to be more realistic.
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?
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.
> 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.
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?
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.
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.
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.
There is currently a debate about these supposed a11y issues. Some are about what happens to focus after dismissal, some are about related elements and announcements, some are about buggy implementations and non support from screen readers.
However it is my belief that these were mostly true 2-3 years ago but the myth has remained. And people still belief there are issues.
I've heard from actual screen reader users that these supposed issues are mostly non-issue. And pale in comparison from people implementing their own.
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.
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.
You can achieve that with grid right now. Set a row to height zero, with a container inside with overflow: hidden, then toggle that row to height 1fr. Stick whatever transition you want on it — job done
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.
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.
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.
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.
> 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.
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.
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.
I can't help but feel that's half the idea. I recognise its an extremely tinfoil response. At least at the low level, it's probably just some dev that wants to make "cool features" but that easily exploited by "entity of the corporation" where it undoubtedly benefits huge incumbents who propose or at least first-past-the-post these features.
It's been many years since you could build and maintain a new browser rendering engine without a lot of money. It's labor intensive enough that Microsoft decided it wasn't worth it.
Today, all the money for this comes from only two companies in the world: Apple and Google (since Mozilla's main source of income is its deal with Google, we have three widely used rendering engines, but the money really comes from two companies).
Now what's interesting about Ladybird is it's this big pile of BSD licensed code that looks like it would be a good start if you wanted to build a fourth engine.
Is there someone out there who has a lot of money and a reason they would want to spend it on developing another engine? I.e. they don't want their fate owned by Apple/Google or the existing engines are somehow inadequate for their needs? This is the really interesting question.
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.
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.
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.
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.
> 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.
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.
Ironic since the reason sticky exists was because developers were sick of managing it in JS. If you truly believe doing it in JS is better, feel free to do it in JS. No one is stopping you.
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.
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!
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.
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.
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?
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?
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/
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;
}
}
> 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.
Insert "they're exactly the same" meme. (Except for more curly braces: fun.)