Old dogs, new CSS tricks | Hacker News Reader

Old dogs, new CSS tricks

mxb.dev

175 pointsmxbck106 comments

>> But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here?

A number of things are in play here.

1) when people ask for something it's because they need it now. The client wants it to look like x. Providing it a year later doesn't mean I'll retro-fit it, I'm working for another client now.

2) the new features on offer are (mostly) not low-hanging fruit. 20 years ago we were asking for the basics - not-table layout (flex, grid), variables (var --), conditionals (@media) and so on. The low hanging fruit stuff. Now "most people" aren't really asking for anything. (The sliver of a minority attending css conferences naturally are dreaming up new edge cases.)

3) most of the websites that exist (aka have been styled) are older than these features. Since redesigns are typically multiple years apart it takes years for them to filter in. As a proportion the number of sites built, or updated, in the last year is small. And the proportion of those needing these features is smaller.

4) most sites are not styled from an empty notepad. Most use (reuse) a framework - either personal or public.

CSS is starting to move from mid-stage to late-stage development. We're well passed the "terrible to work with" stage, well passed the "good enough" stage, and now into the "what can we dream up stage".

That said I can see myself using some of these things - sub-grid and :has being the obvious ones for me.

Yeah, I still remember a site where I really would have needed the :has selector, but I have written a workaround in JS and now I would rather so the whole thing new than fix that tiny aspect.

I will however definitely rely on the has: selector next time I encounter that situation (it had to do with markdown output putting img tags inside paragraphs, so I needed css that treats a paragraph that has a img inside differently than other paragraphs).

Does :has function as a parent selector? That's probably the only thing I ever really wanted from CSS and I assumed it would never happen because of the (back propagating) implications for the order the DOM is rendered in.

Yes, because that was truly a gap in waht could be selected.

Here is a blog post outlining what can be done using :has https://webkit.org/blog/13096/css-has-pseudo-class/

Very good take. CSS is at a point of complexity now where you can't really blame anyone for not knowing everything you can do with it or every new feature that's been adopted in the last couple years, especially for full-stackers like me. I know a lot, including more than enough to get my job done, and though I will still learn new things now and then (I didn't know container queries existed before this article and now that I do I may use them in the future), I'm not in a hurry to learn every new bleeding-edge feature which are probably just going to cause compatibility issues for some non-insignificant number of my clients' browsers (or my clients' clients' browsers) anyway.

Also, as someone who started doing web dev professionally nearly 20 years ago where if it didn't work in IE 6 then you just couldn't use it at all, I just instinctually don't even bother with new (as in 3-4 years old) CSS or JS features most of the time. It's pretty deeply ingrained in me and I suspect many other devs who were around in that time. That said, 5-year-old CSS and JS specs at this point are pretty damn good and you can do a whole lot of cool stuff with them, so this is not nearly as painful now as it was back then.

Good enough is good enough.

> I just instinctually don't even bother with new (as in 3-4 years old) CSS or JS features most of the time. It's pretty deeply ingrained in me and I suspect many other devs who were around in that time.

I'm also a web dev with nearly 20 years and do exactly this as well. Old versions (or any version of) IE crushed our dreams too many times to feel comfortable delivering anything modern, let alone cutting edge.

Same here (>20 years at this point)—I just know how to do nearly everything with existing CSS features, or else I’m already using a framework like MUI that eliminates a lot of the issues the new CSS features aim to solve. For example, the unique class names and low specificity offered by MUI negates the need for the new container functionality.

I’ve definitely used :has() though to replace the need for certain CSS combinators—for example, being able to style a label that wraps a checkbox based on the checkbox being checked, rather than relying on the next-sibling combinator while placing the label after the checkbox input. That’s pretty cool and solves some limitations that existed previously.

As a developer of a similar vintage, I can relate to this mindset, but I think we should be careful about it. We learned in an era when differences in browser behaviour were a big deal and new versions of browsers sometimes came along years apart. But those days are long gone — even Safari now gets several updates each year — and we should let the habits they created go with them.

Should we be cautious about relying on non-standard features or trusting the perma-beta culture that Google never seems to have grown out of? Of course. But there have been many recent developments that are useful and already widely supported, and not using those when they provide a good solution to an immediate problem seems counterproductive.

Yeah, I think the first factor is probably the biggest one here. Devs tend not to rebuild existing sites on a whim, especially not to integrate new technology for the hell of it.

We'll almost certainly see more container queries used on new website/app development projects going forward, but any that started prior to their integration into most browsers are likely going to remain using the old design philosophy with media queries instead.

For me personally, it's because I've been burned too many times by blog posts announcing that "feature X is here!", when in reality, it's only here in Chrome or behind a feature flag, or the exciting parts haven't been implemented yet. Even this blog post falls into the same trap. There isn't good cross-browser support for view transitions or anchor positioning, and yet they're listed as here now.

It does not fall into the trap:

“Granted some things are relatively new, and others might be sort of niche-y.”

View transitions are the perfect candidate progressive enhancement. If the browser supports it, then the user will get the rich animations. If it doesn’t, then they get what they currently have.

And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)

> View transitions are the perfect candidate progressive enhancement.

Quite the opposite. The alternative to "no view transitions" isn't "clunky hard-refresh page-by-page experience," it's single-page view transitions orchestrated by JavaScript (instead of by Chrome). View transitions require you to fundamentally change the architecture of not just a page, but your entire website/app.

> I can’t use [feature X], I need to support [old browser].

And that’s not necessarily a bad thing.

As I commented a few days ago, nowadays devs don’t seem to care too much about backwards compatibility. I like to hold onto my devices longer than most people and it’s a bit frustrating to see that most sites nowadays expect you to be in the latest and greatest. It didn’t use to be like this.

I'm a bit torn on this when it comes to browsers.

We recently had a user email us that our app stopped working for them. After we dug into it it was because their Chromebook was last updated in 2021 and didn't have Object.hasOwn (which a third-party library uses) and it's not even included in most common polyfills either. We fixed it, because I hate these sorts of compatibility issues.

Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.

I think you can expect that for a Chromebook, but a different type of laptop might not support modern Chrome? I remember that Steam uses enough chromium nowadays that they had to drop support for Windows 7 early. Chrome doesn't have quite as long a support window for older OSes as the OSes do for security updates.

Is that true? Windows 7 OS updates ended in 2020, while Chrome continued to update until M109 in 2023[1].

[1] https://support.google.com/chrome/thread/185534985/sunsettin....

Yes, for browsers the window for what qualifies as being recent enough to be safe has shrunken dramatically. I’d be on edge about using a browser that hadn’t been updated in even one year… if I had to use a 2+ years outdated browser, I’d have it locked down (NoScript installed, bells and whistles like webfonts disabled, etc) and be much more cautious than I am normally.

Just a remark on that specific case: Object.hasOwn landed in Chrome 93 in August 2021, and came last to Safari 15.4 in March 2022. My general advice is: never depend¹ on features less than two years old, avoid depending on features less than three years old, and treat two-and-a-half-year-old Safari as a bigger deal than one-and-a-half-year-old any other browser, because of how Safari major versions are tied to major OS versions to at least some extent².

—⁂—

¹ When I say “depend” I mean “break if it’s not present”. A degraded but still functional experience is acceptable.

² I don’t use Apple stuff, so correct me if I’m wrong, but I believe that this used to be the case for macOS but may be fixed since macOS 12 <https://en.wikipedia.org/wiki/Safari_(web_browser)#Version_c...>, and is still the case with iOS et al. I believe iOS/Safari 15 is still the current version on some actively supported devices.

On my 2012 macbookpro I am forced to use chrome or orion since safari is stuck on 15.X. On my 2015 iMac I can still use the current version of safari, but probably not safari 18 when it will come out. So, for now, the cut-off is 10 years. Pretty good I would say.

Yes, macOS makes it possible to install newer Safari versions on older versions of the OS. However, if you are the type that doesn't update your major OS version regularly, you probably don't check for random software updates anyway, because Apple still shows the Safari updates in the same place as general OS updates. From the settings app, it's the same little red update dot regardless of what the update actually is.

I suspect that many people who use old Safari versions are either used to sites being broken, or they use Chrome and don't care. I wish we had more data to verify those assumptions.

One cant update an iphone if there is insufficient free storage, they may have very limited storage and there is no good way to manually move photos and videos to windows over usb or from icloud. People then end up deleting media one by one by hand while taking new pictures and making new videos. It can take a very long time. Most pictures are/feel more valuable than the update.

Totally. The phone problem I think is unavoidable for a large enough organization. At a certain size of company, with enough users, you just have to accept that your tech stack will lag behind for a few years, OR, you're going to spend an extraordinary amount of dev time building backwards compatibility for less capable devices.

I find it silly how some people tack on "just ship a fallback stylesheet" as a legitimate answer (not accusing you) because we all know that it's never that simple.

I just don't use any of the new features until someone complaints about it. If support is there and it doesn't make it impossible to reason about ill adopt it and thank them.

   @container style(color: green) and style(background-color: transparent),
    not style(background-color: red),
    style(--themeBackground),
    style(--themeColor: blue) or style(--themeColor: purple),
    (max-width: 100vw) and style(max-width: 600px) {
  /* <stylesheet> */
  }

It is useful as a selector for people. Best not let that guy anywhere near my code.

> Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year.

What's the connection to security vulns? How does that impact devs not using "a separate stylesheet to support everyone." or ignoring "progressive enhancement"?

Or what's the vulnerability explanation of hasOwn?

It seems it mostly decays quicker on some webby platforms that culturally don't care much about backwards compatibility

Is there a Chrome LTS channel?

Firefox has an LTS version which can be a baseline for features, but which receives security updates at the very least.

I don't know about, say, Chrome 80 line that would receive security fixes but not new features. I also think that would be against Google's interests to have such an LTS line, it would decrease the moat between it an other browsers.

Why do you need Chrom LTS to use "a separate stylesheet to support everyone."?

Because supporting older Chrome releases is pointless: they should be replaced because of their security holes, discovered later. You may, of course, to decide to put the baseline somewhere, but that baseline would be arbitrary.

With Firefox (ESRs are at 102 and even 52) and, to an extent, Safari (tied to iOS releases) there are non-arbitrary baselines, where you know what kind and size of the audience you additionally cover by staying away from newer features.

They point is the same for Chrome - "should" is a wish, not a description of reality, so if you care about users using old versions, you use a fallback method.

Also don't you have stats by version number, what is extra non-arbitrary about LTS?

Security vulnerabilities are found in browsers.

Browsers are updated to fix the security vulnerabilities.

People upgrade to the latest version to get the security fixes.

If a person is using a browser that is years out of date, they are subject to a lot of security vulnerabilities in a piece of software that is constantly exposed to untrusted code.

Using an old browser is unsafe. If you encounter people using old browsers, you should strongly encourage them to do whatever they can to update their browser for their own good. If they do this, a nice side-effect is that you don’t have to support their older browser version.

Yours is s PSA for updating browsers, but this doesn't explain breaking backwards compatibility since newer browsers with security updates don't break older CSS features.

> Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.

It seems very easy to understand the logic here. What part don’t you grasp? Don’t support older versions => this pressures them to upgrade => upgrading is good for their security.

Sometimes you can't even update. I have an iPad that is perfectly fine for browsing. We use it mainly for TV purposes. It doesn't get any updates anymore.

Now, some streaming services do not work anymore, because the website doesn't work. Why? There is no real technical reason for this. For some streaming services I have a collection of the real streaming URL. That still works fine. The problem is not the streaming itself, it's the website to choose the right stream.

That is reasonable though if a missing feature is trivially obvious must-have. Browsers (and standards, and platforms) that are slow to add it must develop themselves better. It’s nice to respect compat if a new way is a redesign based on feedback, e.g. you used poll/select and now it’s epoll/kqueue/iocp with a fallback. But if it is a feature that was simply missing for years, e.g. UIKit adding random useful methods which existed since forever in Cocoa, no respect. Really, you don’t want to support a platform that takes years to wake up. Let their users know that it’s obsolete, they will update.

In my team, we write software for TVs and set-top boxes, as well as modern browsers. TVs don’t get the ipdate support we’re used to on desktop and mobile. The same codebase has to support Safari 6-era webkit as well as contemporary Blink. We still can’t use some of the flex spec let alone the new hotness.

"I can’t use [feature X], I need to support [old browser]."

Any time someone says this it's important to add a caveat of "and I want my site to look the same everywhere". Using @supports means you can feature detect what CSS the user's browser supports and enhance where possible. A user with an older browser might see a less pretty, simpler design with somewhat worse UX, but that's often ok if it's a tiny minority and you can give the users on new browsers a much better experience. The two versions might look a bit different but that's fine.

The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.

Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM.

If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.

Fixing scoping in userland, like with styled components or BEM, is definitely doable but not really the same as having native support for scoped styles in CSS.

There's nothing wrong with those solutions and I've used those and similar plenty, but they are fragile. Those are conventions that have to be maintained and stuck with, and often for scoped style solutions you're also left with a hard dependency on a build step (BEM is an exception there). That may not be a problem at all, if you're using react you almost certainly already have a build and bundle step, but not every project is that way.

You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them. And like all tech debt, it's a triage.

What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.

you raise a very important point: the tooling around CSS is nothing like we have everywhere else. you can get class completion with Tailwind or CSS Modules (which I prefer), but even basic stuff like CSS Variables or SASS mixins are a black hole

I don’t know what tooling you use, but IntelliJ does all that for me, including autocomplete for variables, HTML elements in HTML files or components, and so on.

If you use the inspections, it can also make dead code removal really easy.

Often I only use CSS if I have no choice. I really do try to fix it but I still cant imagine "well written CSS". I look at the 2000 lines of necessities and know some of it isn't even used and other things could be simpler. The process consumes lots of time without much to show for it or worse.

CSS needs a compiler with warnings, dead-code removal, type safety, modularization, standard structuring and "design patterns" - then software engineers will take it seriously.

We do have tools for that though, how would a build tool fit into a language specification? Aren't those different concerns?

Dead CSS code should ideally be a warning on the web platform. This should be in the spec. Browser can probably emit a warning in the console log if there are CSS selectors that are not used. Authors can choose to explicitly mark with a `ignore-unused`, delete them or move such selectors to separate style-sheets that are loaded by the pages that actually use them. With HTTP/3 this makes more sense (CSS modularization) rather than one single massive CSS for the whole site that just keeps growing over time.

That'd definitely be a useful devtools feature! I don't see why it would need to go through the spec process though, browser vendors could build that independently and get it out much quicker.

The answer in my team's case is browser support and especially Safari on iOS. Our UI is quite complex and demanding regarding functionality, visual presentation and accessibility and would benefit greatly from most of these features, especially subgrid and container queries (and anchor positioning, but that feature doesn't exist outside of the latest version of Chrome).

Even though MDN lists most of these features as "baseline" supported, the reality is that a small but still meaningful share of our users are using old iOS devices – especially iPads – and they can't or won't update their operating system to update Safari. Our oldest supported browser is Safari 14 because of Flexbox gap support.

None of the other platforms are a problem, as basically everyone else is using an automatically updating evergreen browser.

I've read a few articles like this in the last few days and I don't understand why everyone is ignoring the elephant in the room. It's 2024 and Safari is still not evergreen.

When people say Safari is the new Internet Explorer, replies always mention how Safari just adopted such and such bleeding edge CSS feature (while ignoring much older features, though), but the truth is many Apple users won't see those features for years, until their devices break.

Apple is stopping both users and developers from enjoying these very same new features they so happily announce. The web is stuck in time, waiting for enough people to update their devices. Just like in the age of Internet Explorer. At least back then people had the option of installing a different browser. So maybe Safari and the apple ecosystem is actually worse than IE and Windows used to be.

> but the truth is many Apple users won't see those features for years, until their devices break

Yet another case of iPads being held back by their software. IIRC, iPads have slower replacement cycles than either iPhones or Macs.

Great article! CSS doesn’t get enough attention - not outside of Tailwind, which I don’t think is the way to go, but that’s another story.

:has() and :is() are awesome.

One issue I’ve had with any of the newer CSS features is that, most of the people I work with don’t know what they do, because nobody use them. So, I have to explain myself in each pull request - but I guess that’s ok, because then people learn.

Agreed, I still prefer to write my own CSS than using tools like Tailwind.

For specific components, I use explicit CSS, but for layout <divs> I use the tailwind shorthand (flex, flex-row, mb-7) and just add those to my CSS as I go so I don't need tailwind as a dependency. It's the best of both worlds.

This is a bad article.

> And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.

Don't you know there are still a fuck ton of people that are still using the old iOS versions with their old phones? I have plenty of them, and they are long term supporters that I just can't shut them off.

There are new css features that are almost harmless and do not affect the usability, some css features on the other hand...

Bit subjective. I thought it was a great article. Lot's of new properties I've never heard of.

It is not hard to keep track of new css/js features, as the articles pop up very often, e.g: https://developer.chrome.com/blog/whats-new-css-ui-2023

Most of us just decide to ignore them, because a significant portion of our userbase stills stuck with old devices. People who agree with this article probably never get accessed to any website statistic dashboard.

For sure, I understand usage statistics and device targets, etc for your audiences. I don't think it diminishes the informative nature of the article. You can be still be excited about new features even if you can't use them for your particular product/audience/etc.

Some comments here are framing CSS as getting too complex. Some folks are recommending the utility-class approach (e.g. Tailwind).

I don't want to argue for Tailwind, but as someone who's used it for ~4 years now, it strikes me that I've forgotten what it's like to have to think about sets of CSS rules and how they collide.

Utility class systems completely remove the need to even consider conflicting rules.

That doesn't mean CSS shouldn't continue to grow though, and I welcome these new features.

I dunno sir, do you just assume everyone knows what these list items are? I would link them to their appropriate mdn article. I think non of the readers know everything about all of the items.

This should be one of those articles one can click around in for considerable time.

Having to select and search made me wonder at what point in time we lost the ability to click on the bullet to select the list item text? Does anyone remember that feature?

> Quick question: how many of these have you actively used in production?

> Container Queries

I haven't used this, but it looks super useful.

> Style Queries

Eh, I'm sure this is useful for situations that don't come up very often.

> CSS Layers

Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this.

> Subgrid

Again, overly complex. Grid could already do everything this can do, more simply.

> Native Selector Nesting

I'm already using this.

> Anchor Positioning

Eh, I already had solutions to this problem, but this seems like it probably communicates intent a bit better. I guess I'll pick that up.

> :has, :is, :where

:has is useful

:is... okay, fine, syntactic sugar.

:where I don't believe in hell. If I did, I'd be against it because burning someone for eternity is inhumane. But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it.

> Logical Properties

Perhaps useful for situations that don't come up very often. Seems complex, but that might be because the thing it's representing is inherently complex.

> Scroll-Linked Animations

Okay, someone who isn't me will probably do really cool things with this.

> View Transitions

Another thing that seems complex, but possibly because the thing it's representing is inherently complex.

i actually came up with a thing where subgrid would be useful, since subgrid lets you denote that a child wants to use the same grid as the parent.

if you wanted to use grid template areas, and you had something that looked like

   <div id="my parent grid">
       <h1>Title</h1>
       <ul>
         <li />
         <li />
       </ul>
   </div>

There isn't a great way to make the <li> adhere to the grid template areas, because without subgrids only direct children (the ul) have coordinate attributes.

I haven't needed to do CSS grids for awhile, but couldn't this have already been done with `display:contents` ?

TIL about display:contents. I’ll have to check it out but it sounds like it does: https://bengammon.co.uk/css-grid-and-display-contents/

Subgrid lets you do it for anything more involved or deeper though.

I think subgrid might give you a freer hand. Because if I remember correctly, the trouble with display:contents is that no other styles you put on that element will affect elements within it. This means shifting all styles down a node, which can be a real pain and have knock-on effects.

`display: contents` has a11y concerns in a lot of scenarios. The `ul` will be hidden from a screenreader and it will be read as `h1, li, li, li...` etc.

It's a neat hack, but it's still a hack.

After having seen a11y written about 100x times in Svelte warnings, it's finally dawned on me that it means accessibility, which is somewhat ironic that I had no idea what it meant all those times before.

Please don't take this the wrong way, but can I ask how you personally find answers to similar solutions when they come up in your work/personal life?

The first thing I do when I see an acronym or word I don't understand is go to Google and type `what is a11y webdev` or whatever. I think you get the idea.

This has been a part of my life for almost 2 decades now so I'm curious how others handle the situation! What made you wait so long to find the answer? Did you eventually search for it, or did you finally read some document that spelled it out explicitly?

Again, genuinely curious! I assume many people operate like I do and there is a line between explaining too little and too much. Understanding how others approach these problems hopefully will help me improve my own communication in the long run.

I would normally do something similar. The context in which I was seeing these warnings was that I was working on a new UI for a VST plugin using web front-end tech, something novel for me so I was more interested in getting it to work before dealing with what the warnings meant.

It was the parent comment mentioning a11y and screen-reader in conjunction that made me make the connection, I just found it hilarious that the term a11y itself is so inaccessible if you don't already know what it means!

> But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it.

May I ask you, are you a front-end developer?

Full stack. Typically Django+React, using React as a component library not an SPA framework. But I've worked on stacks that deviate from that pretty significantly in the not-too-distant past.

CSS layers are completely unintuitive to work with. I really don't see the use case for them. I hoped to isolate Telerik styling with it but it only made it harder to override styling.

Whats the eloquent javascript or think python equivalent for css? is it mdn docs or another? Does anyone know the best active, comprehensive online references?

How else do you really keep up on all the crazy new stuff

It may be ran by Google, but https://web.dev/ is one good source for keeping up with new web technologies

Great Q!

Pretty much everyone in the field knows about MDN (https://developer.mozilla.org/en-US/ )

and https://web.dev

and https://caniuse.com

but the Interop project is newer and maybe flying under the radar:

https://webkit.org/blog/14955/the-web-just-gets-better-with-...

Enjoy!

The state of CSS surveys [1].

1: https://stateofcss.com/en-US

I simply need wide support. I made some websites for a client who receives many 1. older customers and 2. customers from all over the world. I was conscious of the possibility that these customers could have either ancient devices or some highly obscure foreign devices not reflected on caniuse.com.

Now, if your domain ends in .dev you can just assume that your users are up-to-date techies, but otherwise I avoid anything newer than flexbox (which is just so useful).

If you want to use nesting, for example, you will have to give up Windows < 10 and iOS < 17.2. It's a big ask for some sites.

why wouldn't this work?

> You’d need a separate stylesheet to support everyone.

In theory it can, but when you work with 20 other devs all working on the same codebase, tracking those changes can become burdensome.

Are we going to add an entirely new testing suite and workflow tools to save 5 lines of legacy CSS in favor of the new version? Probably not in a lot of teams.

You also need to write and maintain code to conditionally load that fallback stylesheet and hope your users aren't using some weird user agent hacks (looking at you instagram in-app browser).

All of these problems can be solved, but obviously nobody wants to because the juice is not worth the squeeze. This is not our first rodeo. I'm gonna wait another 18-24 months and then start using most of the features released this year. It's fine.

You don’t.

Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5.

Not sure what you are referring to regarding Windows < 10, but Windows 10 was released nine years ago. Only a tiny fraction of web developers need to support decade-old clients.

If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will transcode your nested CSS to older syntax browsers support. Then, when you drop support and remove those browsers from your browserslist, they will stop transcoding it and the CSS you deploy will get smaller. But you’ll have been writing standard nested CSS all along.

If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.

I am referring to the fact that there are no browsers with native CSS nesting that support Windows < 10.

> If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.

Non-& is not “the normal syntax”. It was a late addition to the specification. Both with and without & are normal, but with & has better compatibility.

Even if you don’t use the &, you can still write nested CSS and support older versions of Safari, like I said. Use PostCSS or Lightning CSS. There are normally several areas where you can start writing modern CSS today and fill in the backwards compatibility with these tools. It’s not just nesting.

https://preset-env.cssdb.org

https://lightningcss.dev/transpilation.html

I guess we will have to disagree about what is normal or not. Perhaps it depends what tools one was using before going CSS native.

Obviously I'm talking here about direct serving of CSS assets without precompiling.

If one wants to replicate exact similar behavior in a webapp conpared to a native app we need the scroll/view animation to be available in all browsers. Right now animation is only possible with js and results in jittery animations.

CSS is becoming too complex. The syntax looks like it wants to be output by some compiler instead of being crafted by hand. Personally I also don't have any pleasure anymore writing CSS these days.

Sass and BEM methodology works fantastically well. Naming things isn't that hard, but Tailwind/utility approach is also extremely useful.

Those new features, besides container queries is just gibberish. Layer? WTF? The cascade is bad enough as it is, most devs can't even deal with the cascade it's why Tailwind become so popular. And we should dive even deeper into the cascade BS with layers and scoping and whatnpt? Again, this all looks like it was made to be output by some CSS compilers, not written by a developer.

You don't have to use the new fancy features, you can keep doing things the old way.

I think he means other people will though.

I’m unsure if you have specific feedback or just a general misunderstanding of the point of additions like layer to the spec.

At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have.

There is a concern that one can have too many tools to do the same -- or very similar -- things. This can reduce readability. Consider Perl's many ways approach to Python's (initial) goal of one way.

Every new release of Python 3.x further erodes this idea. I like using the new features because I find Python generally inexpressive and verbose, but I have a hard time explaining to nondevelopers who read the code about the assignment expression, keyword only arguments, structural pattern matching, typing improvements and deprecations and so on.

> At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have.

I don't really stand by GP's comment but I also don't think their concern can be dismissed this easily. We generally write CSS as teams. You'll have to read as much CSS as you'll have to write. Ideally you actually read more than you write so you can reuse existing rules and follow established patterns

Anyone writing CSS for a day-job, an OS project, or even just following a tutorial will have to at least familiarize themselves with these concepts

it's sort of weird, there have been multiple comments where people have responded as if they write CSS all by themselves and there are no colleagues to worry about, and that they also think this is an industry-wide standard!

on edit: just to note I'm generally the old guy who is pushing for people to use 'new' stuff like clamp, min, and max functions and lab color profiles, to no effect.

Good point, I didn't consider this.

I understand that feeling to some degree. At the same time, I think this is just how CSS has always been. Originally we had to style pages with tables and when flexbox/grid came out there were oodles of devs who refused to use them for a while. CSS is an ever-evolving toolset and I like that, but I do understand that change can feel unwarranted to some.

Is your complaint about the features, or the syntax?

I think the syntax is good (getting better with nested selectors)

Who cares when Sass works so well and this is just a subset of what sass does.

Maybe in 10 years time we’ll finally get to what sass can already do today.

The merits and costs of a preprocessor are unrelated to this question.

Just because you don't understand it yet doesn't mean it isn't useful.

An ideal version of CSS would remove the need for SASS, BEM, and any non-thematic framework. That we have to use those right now is a problem to be fixed.

I’ve got the exact opposite reaction to you: the improvements to CSS are making the CSS I write simpler.

> Anchor Positioning

Are there selectors for this anchor relationship? e.g. style anchored element when anchor is on :hover

don't call me a monkey for not using a tool that I don't need, thank you!

> Quick question: how many of these have you actively used in production?

> Container Queries

They aren't useful yet because:

1. Using them requires a wrapper element which can dirty up the HTML

2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases.

Container queries will become more useful when elements can query their own size, rather than their size inside a designated parent.

> Style Queries

A solution in search of a problem. Current selectors are acceptable for most current use cases. May be useful for customizable widget/dashboard style layouts.

> CSS Layers

Nice, but they currently place too many demands on the developer to understand what layers currently exist. These will become more useful as browser dev tools make debugging them easier to reduce the burden on the developer to keep the layers in their mind while coding/debugging.

> Subgrid

Very useful when you need things aligned, especially in things like card layouts. The only thing holding this back is developers who are too reliant on 3rd party framework/libraries, e.g. bootstrap developers relying on grid column classes and tailwind developers building things with margin/padding everywhere. This will take time for developers to shift to, but those developer who limit themselves inside their own framework/library bubbles may never use them.

> Native Selector Nesting

Very nice quality-of-life improvement.

> Anchor Positioning

Only supported by one browser. I have no idea why this was even in the article to begin with. But it will completely remove the need for some JS placement/layout logic that keeps getting reimplemented all the time with pop-ups (pave the desire paths and all that). It also has the potential to make margin notes easier.

> :has, :is, :where

:has is super powerful as a parent selector

:where is great for simplifying repetitive css

> Logical Properties

If you maintain the discipline required to use these aliases over {top/left/down/right}, or if you have a linter to remind you, all of a sudden you're now able to support RTL languages without needing to spend time and money to make a different site for them.

> Scroll-Linked Animations > View Transitions

Both will be abused by marketers and "designers" who don't understand accessibility, but both will also greatly simplify micro-interactions on proper websites that aren't trying to be a "marketing experience".

:has isn't available in Firefox ESR (115) yet. The next ESR (128) will trickle out between July and October.

@property (not mentioned) is only in Firefox Nightly; hopefully it makes it for 128 ...

Only enterprises are going to care about ESR editions, so they're likely already using older code. Any time they are going to need something like :has, they're probably going to achieve it with js anyway.

@property will be nice, but almost every initial use-case will be animation related. That said, I'm happy it's reaching baseline support since more powerful features can be built on top of it.

This article is interesting but when we’re talking about design elements I think it’s always a good idea to include some actual demos or examples showing the final result and not just the “code”. I might also not be the target audience but I still don’t understand what container queries are or what old paradigm they’re replacing. The author does a good job explaining the difference between border-radius and the old way of using photoshop, but fails to do that for the features that he’s trying to promote.

Old paradigm (media queries): You make layout changes based on the width / height of the viewport (browser).

New paradigm (container queries): You make layout changes based on the width / height of the containing element.

This lets you layout a component so that it looks good in any sized container. Picture a component that might be in the main section or in the sidebar - you can now just style directly based on width of the container instead of having to know the total width of sidebar + main section and do the calculation using viewport width.

Agreed, but to add to this:

media queries are still useful, and since a media query may hide/remove entire containers in the view then the remaining containers may have widths that are no longer a simple proportion of the viewport width (or other property being selected for).

So container queries can also enhance styles with media queries, not just replace them.

Reply on news.ycombinator.com