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.

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.

See their events https://html.energy/events.html

What bad patterns are encouraged by design in Rust?

• complicated types
• complicated macro
• premature optimizations with lifetimes among others

Let's create a project and benchmark it :D

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.

How a rewrite in Rust is beneficial to read many files? Because it avoids allocation.

Note the program was written once in JS then in Rust.

Différent ways to handle errors in Rust.

In favor of the clap crate that allows delevopers to build quickly in Rust.

Structurally speaking, then, a paragraph is a group of related inline elements. In this case, inline words, but it could also include any of the items described as “phrasing content"

<hgroup> issu the tag to use for heading with multiple inline content.

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.

The naive Rust implémentation is 10 times faster than the python one.
It remains 6 times faster than the optimized one.

The Python has a collections.Counter class that is approximately as fast as the naive Rust version.

There are 3 error or exception handling: unchecked exceptions (JS), Checked Exceptions (Go) or an integrated type (Result in Rust) that handle one case or the other.

Explicit is always better.
One thing with an integrated type, is the normal case and the other case. That's a great type to handle more than errors: a lookup of a key in a map, opening a file with a name for which there is no file is normal business. Maybe I will find more.

And for quality software, its function must be so blatantly obvious that everybody thinks: wow, this is trivial code, even a monkey could've programmed this.