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.
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 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.
> 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.
> 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.
> 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.
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).
> 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.
> 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.
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.
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.
>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.
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.
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.
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
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.
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.
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`.
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.
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
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 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?
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 :/
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.
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?
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.
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)
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.
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.
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.
> 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
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.
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.
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.
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.
> 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.
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:
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
152 comments
[ 3.3 ms ] story [ 231 ms ] threadBut 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 beat myself up about performance issues like that all the time and have to catch myself to go do something more useful instead.
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.
[1]: https://www.stetic.com/market-share/browser/ [2]: https://gs.statcounter.com/browser-version-market-share/desk...
https://caniuse.com/?search=CSS%20nest
Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.
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.
Edit: not so much large corporations tbh.
I guess if they just put their machines to sleep and never fully quit Chrome, it never has a chance to self update.
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.)
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!
The key feature would be to maintain the exact state of a tab between process restarts.
Then they could restart the whole browser without the user noticing
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.
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).
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.
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.
Sent from my iPhone running iOS 16.
Vanishingly few, though. Again, there's data in the upthread links, and it says that after two months a stale release has effectively disappeared.
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.
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.
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.
I get that it took some engineering changes on the parser front, but this is so much cleaner as far as syntax goes.
If you're running some fun unpaid sites like me, then screw everyone with an out-of-date browser, I'll do what I want.
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.
https://developer.chrome.com/docs/css-ui/at-scope
https://github.com/mozilla/standards-positions/issues/472
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
That's an interesting way of saying "Firefox is not backed by an unlimited pile of cash"
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.
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.
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 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.
I don't use svelte much, but Vue, Lit, and Surface all have the same css scoping stuff too, and it's wonderful.
[1] https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
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.
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.
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.
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
And this is different from any other environment... how?
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.
There's also transform+animate module as well but I won't worry about that much.
[0]. https://css-tricks.com/snippets/css/a-guide-to-flexbox/
[1]. https://css-tricks.com/snippets/css/complete-guide-grid/
[2]. https://css-tricks.com/a-complete-guide-to-css-media-queries...
EDIT: Formatting
- How is it supposed to be fun?
- Why not just stick to the most basic, simple and widely supported CSS rules?
Then you are back to using tables.
(though 'read everything on MDN' is always an option)
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
Who knows.
https://www.joshwcomeau.com/
https://web.dev/learn/css
Muchas gracias.
A basic working knowledge of CSS will still serve you after Bootstrap/Tachyons/Tailwind are no longer flavor of the month.
Anyone know of any links regarding this? (Remember when blog posts had links?)
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.
0 - https://world.hey.com/dhh/once-1-is-entirely-nobuild-for-the...
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.
https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting...
https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
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.
https://github.com/mozilla/standards-positions/issues/472
https://connect.mozilla.org/t5/ideas/implement-css-scope-rul...
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.
https://news.ycombinator.com/item?id=37015592
Firefox might be coming to an end, sadly.
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.
> 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.
Relative OKLCH colors aren't available on Firefox as of today: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...
Here's a page with example gradients in SRGB and OKLCH, in which the second gradient does not show if viewed on Firefox: https://www.learnwithjason.dev/blog/oklch-better-color-css-b...
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
https://www.smashingmagazine.com/2022/01/modern-fluid-typogr...
Such a nice property, makes responsiveness much easier to build in
See also:
https://utopia.fyi/
https://cube.fyi/
https://caniuse.com/?search=%40apply Article says it’s dead and replaced with something completely different that makes no sense.
Seems there is no champion anymore pushing it forward: https://discourse.wicg.io/t/needed-new-champion-for-css-appl...
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/length#lh
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
So effectively the Soviet Union never ceased to exist on the Internet.
https://en.wikipedia.org/wiki/.su
all credit to @fat, whose talk on the Cascading Shit Show is sadly no longer on youtube. At least I still have the socks.