My favorite new CSS feature is the Custom Highlight API, which allows you to style arbitrary (and potentially overlapping!) text ranges without needing to create ad hoc <span> element nodes. MDN Demo:
Hopefully VSCode will be able to switch to using this API for syntax highlighting in the near future for a performance boost, instead of sticking to the current superposition approach:
I agree with the article, CSS has got really great. I was gone for 10 years (jail) and before I left CSS was still a real bear with tons of little hacks and killing yourself to make floats work. The biggest change to the Internet when I got out was that CSS was rather lovely and for the first time in 30 years of web designing I actually enjoy doing layout.
I'll have a party though the day CSS Masonry layout is no longer hidden behind flags:
> All of these features are available today, as of this reading, with every major browser supporting them in the current version
That may be true, but most people don't update their browser every month[1][2] (data isn't readily available it seems, but I'm sure as a webmaster you'd be logging User-Agents and can see the long tail for yourself). So if you want or need to reach a wide audience—say, if you're writing a storefront for a business, or an e-government portal—the only new features you can use are those which fail gracefully, namely ones that are syntactically valid under the old spec+parsers.
The “Baseline” initiative now has a useful suggestion: their “wider support” high compatibility status is “all major browsers have been shipping it for 2½ years”. See https://github.com/web-platform-dx/web-features/blob/main/do... for more details. (When they first announced Baseline, its definition was disastrously bad, generally only covering ⅔–¾ of actual users, but I’m pleased they’ve listened to feedback and redone it completely; the definition it has now is a little more conservative than I’d have gone for—I’d have gone 2 years—but that makes it even more dependable, where that status is achieved.)
Picking jut a couple of these specific features:
• CSS Nesting as a whole is only 4–8 months shipped, and the “relaxed nesting” only shipped earlier this month in Chromium and Safari. At this point, you should absolutely not “drop those extra &”, and almost certainly not depend on nesting at all yet. And since it’s syntax, it’s not really a progressive enhancement candidate. So this becomes just a “don’t ship nesting syntax for another year or two”. Author with it and transpile down to compatible syntax with something like Lightning CSS, by all means.
• color-mix() is only 7–12 months shipped, though as a saving grace it’s Safari that’s the oldest (Safari is the browser most commonly far out of date in features due to Apple’s tie-browser-updates-to-OS-updates approach). It’s not generally a good idea to depend on color-mix() yet, though there are some progressive enhancement cases where it’s reasonable. For example, `text-decoration-color: color-mix(in srgb, currentcolor, transparent 50%)` makes underlines semitransparent, and it probably doesn’t matter if the browser skips that.
>Safari is the browser most commonly far out of date in features due to Apple’s tie-browser-updates-to-OS-updates approach
I love Safari, it's my browser of choice, but this behavior must change. It's easy to miss an OS upgrade (it's a big deal, takes time, may break things, etc) and as a consequence, being 3-4 versions behind is not uncommon. People end up switching to Chrome on old systems because sites are broken in Safari. Evergreen browsers have been the future for more than a decade. It's the only way to go.
Does anyone actually really care about the compatibility still? For quite a while now, I have relied on PostCSS/Vite presets just doing the right thing, transpiling my CSS to whatever is most compatible. And that’s how it should be - from all the important things to know about the web platform, developers really shouldn’t spend their time fine-tuning compilation artifacts by hand anymore.
Syntax features like CSS Nesting can be translated into something older browsers can understand. But other features either can’t be translated, or can only be translated in some cases. For example, color-mix(in srgb, red, blue) can be computed as purple at compile time; color-mix(in oklch, var(--a), var(--b)) can be computed iff --a and --b are known to have single static values; and color-mix(in srgb, currentcolor, transparent 50%) fundamentally isn’t known until runtime (even with DOM knowledge, you can’t say “currentcolor is always purple, therefore, &c.”, because the user agent may force colours).
So yes, you absolutely still need to care about compatibility. This isn’t about fine-tuning compilation artefacts by hand, this is about browsers lacking features that you’re trying to use.
Wow, I completely missed the news on relaxed nesting making its way into browsers. That's fantastic. The whole "you should usually include an ampersand, but sometimes it's not required" rule was really frustrating as a concept.
I get that it took some engineering changes on the parser front, but this is so much cleaner as far as syntax goes.
I reckon it was a mistake and they should have always required an &. But when they were surveying, they refused to even consider this option for reasons that I don’t recall but which I think seemed weird to me.
> Shouldn't browsers update themselves these days?
Looking over the shoulder of a user who’s fairly savvy—but doesn’t understand just how horrifying browser security is—revealed at least one pitfall to me: an update needs a restart of the browser, and a prompt to restart appears specifically when the user turns to the browser, presumably, in order to use it, that is, at the worst possible moment. As a result, it gets postponed indefinitely.
(Forced restarts when the browser thinks you’re not using it are also a bad idea for reasons that are hopefully obvious to anybody who’s used a modern version of Windows. That is not even counting the general vibe of knowing better than the user what they want, which I just instinctively dislike.)
Just like Chrome had a whole thing about process isolation to avoid crashing the entire system, it would be quite excellent if they could figure out how to effectively update at a tab-based level. New tab? Get the newest Chrome in the tab.
Obviously would be quite frustrating to debug a thing only to realize tab A is version 1 and tab B is version 2 of course. And it seems like it would require a massive amount of effort. Would be cool though!
If you use an ESR browser, you’ll get security updates, but not new features. Some users prefer this as providing more stability and possibly better security.
Firefox ESR is updated with new features about once per year, so that’s probably the minimum time one should assume for new features to become universally available.
> Shouldn't browsers update themselves these days?
They should. But in the same way, admins and guidelines in authorities and large corporations should now follow a more modern update strategy. "Never change a Running System" is unfortunately still a popular, lazy excuse.
In a way I can understand them - there are often things people are used to breaking or changes in the UI with software updates (not so much with browsers usually I guess).
I can sympathise with older or less technical people who are afraid of an update forcing them to “relearn” how to do something they are used to.
I don't know exactly when this changed, but I always see people (devs and users alike) leave their Chrome open and waiting for an update, sometimes for weeks or months.
I guess if they just put their machines to sleep and never fully quit Chrome, it never has a chance to self update.
Am I crazy for thinking that Chrome should be designed in a way where individual tab rendering processes should be able to upgrade without having to close and restart the entire cluster of processes? The actual browser UI shell very seldom needs updates...
I don't know the internals of chrome (I'm sure someone else here does), but that sounds like they'd be containerizing a bunch of runtime inside tabs. Would probably blow up memory usage. But not sure what their current tab sandboxing already entails.
> Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.
They should. But we have iPhone users who get an update to their browser every 6 months(?) and even then, it's still behind on features most of the times.
Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.
That requires a mutable filesystem, which also seems silly from a security perspective. It would also require granting permission to mutate/replace executables to a program that's exposed to untrusted input (i.e. a browser).
> That may be true, but most people don't update their browser every month[
Yes they do? All modern browsers are updated automatically with the OS. It's true that not everyone is on exactly the same cadence and there are always stragglers, but if you look at your second link the time to decay to near zero for any given browser release is almost always two months from the release of the next.
It's a horrifying thought, but the truth is... some people don't upgrade their OS very often. Or at all. Or as the sibling comment says, they use an Android phone or iTrinket that isn't getting updates, limiting what apps can be installed.
Can anybody recommend a from-scratch introduction that follows the contours of modern usage? I can certainly find introductions myself but I don't know enough to know which are sensible.
(though 'read everything on MDN' is always an option)
Great resource. It is just ironic that the collapsed content of each item needs JS to be expanded and the collapsed content just contains a link to a new page. The collapse is needless at all. Even it is needed, it is easily to expand it with pure modern CSS.
This course came out somewhat recently and I think it's designed for people who came to Frontend development mostly from JS/Using React: https://css-for-js.dev
But I've been thinking about making a course that specifically focuses on helping people who have been doing web development for a long time update their skills. Because CSS has added so many modern features but it's easy to not notice if you're already tethered to a pre processor and have been using one for 10+ years
I'm a professional software engineer that has paid for numerous books and similar learning material, and even then $399 is steep for me (and yes, I know there are cheaper packages, but they only get you part of the course).
I'm not the target market for a video course -anyway- but it wouldn't surprise me if that price point results in "fewer sales than a lower price but similar revenue and a more pleasant discord due to student investment" or so.
You might not need jQuery (https://youmightnotneedjquery.com/) shows pure JS implementations of common jQuery methods. Someone should create an analogous You might not need SASS to help developers move to pure CSS.
One thing I’ve really liked about using Svelte is that it’s nudged me towards using plain CSS. Since styles are component scoped it’s allowed me to just focus on applying them in the small, which I think reduces some cognitive load for me. And I’ve been surprised at how much I enjoy solving problems with pure CSS.
Yeah, scoped css is key to reducing all sorts of complexity.
The BEM approach in all is craziness is basically an attempt at scoping. And then tailwind too is trying to solve many if the same problems, from the opposite direction. In both cases people end up using their component frameworks and JavaScript libraries to build new abstractions atop the hacks to try and scope css, and the pile grows.
Real scoped css with @scope has actually landed in latest Chrome and Safari, but Firefox are dragging their feet.
It's not an issue of having the resources to implement the spec -- it's that they're not convinced of the value of the feature, especially given it has the potential to impact performance.
I personally think they are vastly underestimating the enormous potential upside for the whole Internet if devs can make style changes with confidence, and frameworks like Vue and Svelte don't have to keep bolting on bespoke, expensive JavaScript-based approximations.
Sorry for being dense, but what’s the difference between this and nested styles that just landed in every browser? I still scope my styles to a particular selector in either case.
Scoping let's you define an upper and a lower boundary
So you can cut holes in the selectivity, for say, letting blog post content have its own styles. That's the biggest advantage. There's also some minor utilities it's got, like not impacting selectivity and such, but it is one of those features that will have to see widespread use to actually grow an understanding of all it's intricacies
I don't know how it works in Svelte, but react+MUIv4 (makeStyles) is effectively component scoped as well, in that your selectors will have a random prefix generated unique to each component.
I actually find this really obnoxious. Its super common to want a child component to change styles based on the parent component its wrapped by, sometimes far up the tree. The only way to do this is prop drilling to pass a class, or start putting vanilla selectors everywhere the parent can target. I don't really see the usefulness. CSS isn't naturally isolated like that.
From my experience, this is a natural reaction at first, but there aren’t that many use cases that warrant global styles when you’re working in a component-oriented framework.
Passing props or using state is the way to tell a child component to dress differently, even though it sometimes gets burdensome. Anytime I tried using global styles, at some point something went haywire I didn’t account for.
On the other hand, for styling HTML generated or fetched from somewhere (e.g. CMS content, rendered Markdown), it’s obviously necessary.
I disliked it at first too but now I consider migrating to such solution.
I am starting to tolerate CSS as a set of style properties, but I still hate CSS as a stylesheet files with various rules with unclear dependencies. Very quickly they become extremely brittle. It is also hard to modularize them in any sensible way. Unless your web app is one SPA with one set of CSS files any change is risky and may affect multiple pages in surprising ways.
Author of the blog post here. I've felt the same way. I wrote a big article griping about tailwind[1] earlier this year, that was somewhat controversial here on hn, but the feelings extend to other bolted on attempts to "fix" css throughout the past.
I don't use svelte much, but Vue, Lit, and Surface all have the same css scoping stuff too, and it's wonderful.
We write Lit at work, same story though. I almost never even use classes anymore because my JS and CSS is scoped. `foo-card`? Nope, `article > div > span`.
CSS Nesting will definitely be great to use in future projects, and I'm super happy to see it in vanilla CSS now.
But to be honest? I think CSS was fun for a while, simply because all the stuff mentioned in the intro of the article removed many of its pain points. Flexbox, Grid, the is selector, cascade layers... all of this stuff just lets you simplify your CSS down to something that actually makes sense rather than a big ball of mud and browser hacks.
I will say however that I've never really got to use those fancy colour properties though. Feels like every time I've worked on a website or app for any remotely large company, the design team had some set in stone idea about what the branding should be and would accept zero deviation from that in terms of what colours could be used for text, backgrounds, etc.
I had the opposite thought -- I bet the new color mixing will increase payload size. Which of these would you rather send over the wire?
A) color-mix(in srgb, var(--primary-color), white 50%)
B) #abcdef
For me to give up scss, there needs to be a minifier that calculates colors ahead of time and emits them plain, the way scss does. (Maybe there already is, who knows)
That will make zero difference to site performance. If I didn't have uBlock running, half the sites on the Internet have 100MB+ payloads now. You could save more than those 50 compressed bytes of text by just optimizing one image on your site :)
I beat myself up about performance issues like that all the time and have to catch myself to go do something more useful instead.
Perhaps it's nostalgia, but I feel like the initial "material" concept—UI components being like stacked paper—was better realised in 1 (and 2) than in 3. It wasn't the first minimalist design framework, but the spec was notably thorough in a way the new one isn't. I also preferred the barely-rounded corners and standardised colour palettes, but that's more a matter of taste.
I don't think this person actually worked with CSS in the early days. The clearfix trick was back then, not now. It was back "in the day" that we had to do shitty workarounds like clearfix. Like CSS wasn't fun back then, at all. CSS wasn't fun, then not fun, and now fun again. CSS has been on a steady trajectory out of awful but it works, to predictability, and much more fit for purpose. React and the like have allowed for tight namespacing which makes collisions a thing of the past, and so the "cascading" element is less of a problem.
Indeed I was. No one actually liked clearfix, but we had to do it. It was the bit of plaster smeared over the hole the door knob punched in the wall. A necessity, but not a nice one
But CSS isn't "fun again" if it wasn't fun before. And it certainly was not fun before, it was a horrible nightmare of non-standard implementation and an ill fit for what designers wanted to do.
I've been re-learning CSS this year in order to work on my website and it's been amazing. Variables alone changed everything and I can't believe it's gotten nesting support already. Things like SASS are simply not needed anymore!
And it keeps getting features I couldn't even imagine. Scopes are awesome and will make selectors less complex. Those color functions are going to be very useful too, I spent way too much time fiddling with colors on my website and I have no doubt they're going to make things much easier.
Someone who clearly didn't get it was wasting three years time "well actually"ing everything. The latest news is "it's worth prototyping". Meanwhile Chrome has released it(steam rolled?) and Safari has it in tech preview.
I question if FireFox has the resources to keep up with the pace of the modern web.
Mozilla has over a billion dollars in the bank but they're focusing on raising executive salaries and ineffectual agenda pushing over spending on Firefox development.
Yeah, I read complaints from people about more and more sites not working after updates and over time (banks, etc).
How can they fulfill their mission if they aren't meeting users where they are at and being aggressive about being the best browser experience for users and developers?
And they can't do that by thinking they know better than everyone else. They need to read the room and know which way the wind is blowing.
The problem with things that are not needed anymore is that they won't go away.
Finally CSS has also these nice QoL things that SASS has, then SASS would add new things simply to provide value.
Finally Javascript has all these nice things that make the framework redundant, then the frameworks add new things, of value, and remain relevant.
After a couple of iterations of these sorts of arms races, we suddenly have a big and complicated $BASE_THING, and an even more complicated $ADDITIONAL_THING.
It never ends - complexity in a specific software technology tooling, processes and development, much like entropy, only increases, it never decreases.
> All of these features are available today, as of this reading, with every major browser supporting them in the current version
> This mixes your primary color with 50% white, in the sRGB space. You can use other, newer, better color spaces too, such as OKLCH, which is my favorite.
> it had gathered a reputation of being brittle and difficult to work with.
For the most part… NO.
At least 98+% of the cases I have seen of developers getting frustrated over the “limitations” and “warts” of CSS has boiled down to a lack of understanding of the cascade; a fundamental feature of CSS that IMO produces nearly all of the frustrations that un-/under-skilled devs run into.
If CSS is being inconsistent, you need to look at the cascade from both ends: from how CSS applies it’s styling, and from how HTML is assembling the content (which can also break the cascade). One way or the other, the problem is nearly always an issue of implementation.
Source: doing web pages since 1993. That’s 30 years of experience speaking.
I think most notable and major changes you need to know about are the new layout models. Flex[0] and Grid[1] and media queries[2] and you're mostly up to date.
There's also transform+animate module as well but I won't worry about that much.
For layout I do recommend The New CSS Layout by Rachel Andrew (https://abookapart.com/products/the-new-css-layout) it is a few years old now, but not much has changed in layout since it was published.
It's been around for a bit now but i would add the `lh` height unit.[0] a much more recent addition is popover[1] for dialogs which will be in the next firefox
> display also became animatable, so now you no longer have to figure out how to move an element between hidden, shown but not visible, and shown but visible.
Anyone know of any links regarding this? (Remember when blog posts had links?)
That's kind of crazy. The display none doesn't apply until after the animation is complete?
I'd still want to remove it from the DOM when the animation finishes though
Calc deserved more attention in this article; it's really amazing what you can do with it. I'm using it in an application to center content inside a flexible container.. Using calculated padding.
One of the coolest new features on the horizon is the anchor positioning system.
CSS is still frustratingly complicated and nuanced in a way that's typically opaque to developers. For instance why do you need min-width/min-height 0 on nested flex containers to prevent unexpected overflowing? The answer is surprisingly complicated.
With all the recent CSS improvements I still miss the possibility to have working transition to "height:auto". The issue [1] on csswg-drafts is the most upvoted one. At least we can now use css grid and track sizes transitions, but it's far from intuitive, transition for "height:auto" should just work.
I don't know, I still find designing user interfaces with text exceedingly awkward. Is there any good (FOSS, offline) drag-n-drop designer like those we had twenty years ago?
This post by DHH [0] showed me that I need to take a good look at current CSS. (Scroll down for the styles screenshot)
I kept up with custom properties and some newer colour management but then kinda stopped. So now it's back to basics and re-evaluate how I approach styles. Not that all the features are required at all times, of course not. But it always pays to keep up with the underlying tech. And I find CSS uniquely fun to lean, as the feedback loops are nigh instant.
Some people actually enjoy designing and styling a website, imagine that. It helps when you aren't fighting with the language and can easily express what you want.
Given the increasing number of people using page builders and no-code tools, these novelties are, in practice, either invisible or delayed for a large portion of websites until it makes business sense for the companies behind the software powering these tools.
I think in general that the accessibility of CSS and HTML5 kinda sucks.
Hypercard and Flash are both great examples of the sort of creative cottage industries that can emerge when you provide more accessible means of building stuff. There's like a generations of designers that grew up playing with these sorts of tools.
I'm glad Figma is around now, but yeah, the creative authoring experience is really sad these days. We don't even have a modern equivalent to Dreamweaver or Frontpage anymore :/
It takes milliseconds. You can time it yourself in the inspector and throttle the CPU to like 1/3 speed.
I'd wager CSS is never the bottleneck. I've never once seen it be a performance issue, personally. Browsers are really really fast at rendering the DOM and styling it, especially if you only need to do it once at page load.
Even modern CSS isn't really that complex compared a hundred page Indesign file, for example. Computers and phones can handle it just fine.
If websites feel slow, IME it's usually ads/analytics, slow AJAX and backends, or scripting bottlenecks, loops, unnecessary redraws, efc. Not really basic DOM draws from CSS.
From the point of view of the individual CSS developer, this is of course not a problem. It is the total sum of all small electricity consumers over millions of devices that should worry us. But, as a technocrat, I believe we will find other solutions than a „software electricity consumption“ diet.
Even by that standard it's a non issue. Just keeping the screen on takes more power. Watching TikTok for a few minutes, playing a game, watching porn, arguing on a social media app... just about anything else a phone does takes more power than rendering a web page. This is literally 20 year old technology we're talking about, optimized to heck by one of the world's biggest and most engineer driven companies.
If we're worried about electricity (and we should be), we should focus on renewables and storage and nuclear, not cell phone usage. It's trivial and totally dwarfed by desktops, TVs, HVAC, light bulbs, cars, just about everything.
I share your view (except for the part about nuclear reactors, which doesn't belong here).
But that's not what I mean. It's the sum of all the small parts (not just CSS functions that are offloaded to the client) that, taken individually, all consume only a very, very small amount of energy but are at the same time easily avoidable or without real benefit.
Software and IT are full of these, and the total amount of energy wasted is enormous. But every single developer thinks that in comparison, it's practically nothing.
> Software and IT are full of these [small wastes, easily avoidable or without real benefit], and the total amount of energy wasted is enormous. But every single developer thinks that in comparison, it's practically nothing.
I mean, are they wrong? Think of it this way: A phone running 24/7 at 100% CPU will draw, what, maybe 20W at most? That's 1/5 of an old light bulb, of which many still remain.
But the phone isn't running at 100% CPU all the time. It takes literally less than a second to render the CSS, and 20x less power than a desktop PC would've used just a couple decades ago. In exchange, that's creative work for someone, a (hopefully... not always) better design for the user, and some value for the business behind it all.
On a output/watt basis, that's probably MORE energy efficient than most creative human endeavors. How much energy does it take to make a single ceramic cup? A piece of steel art? A watercolor that takes raw materials from around the world made in different factories, several hours/days/weeks to paint under artificial lighting and climate controls, etc.?
If software is a wasteful form of human energy use, well, probably most things are, and at orders of magnitude worse.
I don't know what's easily avoidable or wasteful about CSS: it's literally the most basic way of formatting a webpage. Is Markdown or a Word doc similarly wasteful? I bet either is less optimized than plain HTML + CSS. What's the alternative here? Plaintext web pages? Gopher? They're not going to save meaningfully more energy. Phones idling and waiting for the next cell tower message are going to use more power than processing some CSS. Literally powering the LED screen takes more power.
At the micro scale, generational improvements in energy efficiency gained from improved semiconductor processes more than offset any incremental loss from a slightly more complex CSS selector -- by this I mean you can compare the power usage of a old desktop rendering a HTML 1.0 webpage with any budget cell phone today rendering a modern webpage. The latter is going to use much much much much less power, despite all the CSS and frameworks and cloud services and whatever.
There are some things that are worth optimizing, like maybe data center power and cooling draws. But at the level of the CSS on an individual webpage? It's not worth wasting brainpower on. You probably waste more calories (and thus fuel input for human metabolism) just thinking about the problem than anything you'd save from solving it...
----------------
edit: I'm reminded of https://solar.lowtechmagazine.com/power/, a site that's always annoyed me because it's so much virtue signaling with so little actual virtue. The amount of energy infrastructure it takes to individually power a website like that out of someone's backyard, the time it takes to dither the images, the battery maintenance... it's so pointless, all just to serve a few HTML pages at 2W. 2W for a site that small? It would use LESS power in a proper data center, statically cached at a CDN alongside a billion other files.
I don't know why there is this movement towards pretend-optimizing irrelevant things, but IMO they are a total distraction (or at best an artistic inquiry), not real power optimizations or climatic solutions. I think it annoys me because there are so many REAL problems (and real solutions!) that need our collective attention. That annoyance isn't directed at you, just general angst about the state of the world lol
I don't think efficiency is synonymous with frontend development.
Words that come to mind - technical debt, framework lock in and dependency hell. Just to name a few.
Isn't it a waste of human potential for people to spend time at a computer trying to push a few pixels around, when `display: flex` will solve the problem in a fraction of the time?
It is. At some point, when the co2 consumption is priced into everything, more users realize that all the grafted tools and libraries are just anxiety with bling bling and you should actually focus on the content instead of the exterior, they will rediscover plain old html. /s
I think at this point I'll just leave modernizing the CSS to experts and use frameworks like Tailwind or Tachyons or whatever. It's just not interesting to me.
I mean, I have some understanding of CSS but at some point the time I spend learning it is not worth it. I don't mean to have zero knowledge of it though, I can build a website with grid and flex and whatnot.
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Custom_...
Hopefully VSCode will be able to switch to using this API for syntax highlighting in the near future for a performance boost, instead of sticking to the current superposition approach:
https://github.com/microsoft/vscode/issues/175938