How to handle CSS color with the new CSS color functions instead of SASS?

The best seems to be color().
There is also rgba(), hsla() and color-mix()

• color()

It’s evident that there is a growing array of new CSS capabilities that can handle many tasks we previously relied on Sass for.

Yes indeed. Also I agree: it's a per project decision to make.

How to build a mansory layout that works. 66 lines of JS.

CSS builds results in faster loading times.

Buildless CSS has also advantages.
But the @import nesting must be avoided.

The author focus is on https://kelpui.com/docs/tools/install/
Get what you want of the CSS library and it spits out the import

font-size-adjust: ex-height 0.5 instructs the browser to scale the font such that the letter "x" is exactly half of the box.

A use-case for font-size-adjust I find much more compelling is that you probably are going to use several fonts on a web-page. And you also might change fonts in the future. And they will have different intrinsic size because that’s how the things are. Part of the mess is avoidable by pinning the meaning of font size.

0.53 is the invariant ratio for Helvetica.

I totally agree.

1. When there is more than one text directionality
2. When the respective expression would be shorter than the non-logical equivalent.

The second point is healthy for every project.

Instead of BlurHash that needs aditionnal JS for 83 bits string, some CSS snippets can do the work for Low Quality Image Placeholders (LQIP).

The big disadvantage of pure CSS approaches is that you typically litter your markup with lengthy inline styles or obnoxious data URLs.

A blurHash like method in CSS can also be used and that's what the author is describing.
A more simpler solution is to use one color as placeholder.

tl;dr: the issue isn’t the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.

The experience shows that atomic css files is not optimal.

If the files I was importing were larger, it might make sense. As tiny, modular files? Not so much!
The complete library concatenated and gzipped is less than a single HTTP request. It’s just over 25-percent of the transfer size of sending modular gzipped files instead.

There are many methods that break performance and accessibility such as dynamic css classes and div and span soup.

Topics adressed from the outline:

1. It’s not just bad HTML – it’s meaningless markup
2. Semantic rot wrecks performance
   1. Big DOMs are slow to render
   2. Complex trees cause layout thrashing
   3. Redundant CSS increases recalculation cost
   4. Autogenerated classes break caching and targeting
   5. Animations and the compositing catastrophe (with properties triggering the layout engine)
   6. Autogenerated classes break caching and targeting
3. Semantic tags can provide layout hints
4. (AI) Agents are the new users and they care about structure
5. Structure is resilience, isn't optional

Likewise, content-visibility: auto is one of the most underrated tools in the modern CSS arsenal. It lets the browser skip rendering elements
that aren’t visible on-screen – effectively “virtualising” them. That’s huge for long pages, feeds, or infinite scroll components.

and I didn't know about the contain CSS property.

contain: layout; tells the browser it doesn’t need to recalculate layout outside the element.
will-change: transform; hints that a compositing layer is needed.
isolation: isolate; and contain: paint; can help prevent visual spillover and force GPU layers.

@view-transition {
  navigation: auto;
}

::view-transition-old(root),
::view-transition-new(root) {
  animation: fade 0.3s ease both;
}

@keyframes fade {
  from { opacity: 0; }
  to   { opacity: 1; }
}

To animate a thumbnail between two pages, the <img src=""> tag can be set to view-transition-name: product-image;

This is a microcosm of a much bigger theme: browsers are evolving to reward simplicity and resilience. They’re building for the kind of web we should have been embracing all along. And SPAs are increasingly the odd ones out.

SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.

and I agree, SPAs are overkill for 95%-99% of the websites.

For reasons we'll get into later, Tailwind decided to burst on to the scene and become the default styling solution for all modern web development despite taking each and every one of these problems, exacerbating them, and applying them to places that didn't have them before

Good things for Tailwind:

This is a good thing, an unironic win for Tailwind. More than anything else, this is what a large codebase with multiple frontend devs needs: a rigid set of global constants that everyone is strongly incentivized to use.

Ok but why o_O

Still interesting, but I already have few use cases for container queries. Maybe because I am too dependent of design that uses screen sizes.

All I see so far is this will need more computation or battery drain for this.

The library is available at https://github.com/Specy/liquid-glass

A transition to open or close a modal

(via https://warriordudimanche.net/article2114/6825e02dcfcba)