Some different ways to write HTML

em unit compound when value are greater or lower than 1.
Except that, they are awesome :)

Bound checking costs 0.3%

The table is available as PDF https://dr-knz.net/programming-levels/prog-skill-matrix.pdf

How CSS handles things already.

#todo what does CSS handle?

Put an id inside the <details> body

Raw match() is fine

interpolate-size is a way to animate height: auto or width. It is only supported in Chrome for now.

A quick example:

@supports (interpolate-size: allow-keywords) {
  :root {
    interpolate-size: allow-keywords;
  }

  details {
    transition: height 0.5s ease;
    height: 2.5rem;

    &[open] {
      height: auto;
      overflow: clip;
    }
  }
}

A more generic one:

:root {
  interpolate-size: allow-keywords;
}

details {
  --calculated-details-padding: var(--details-padding, 1em);

  transition: height var(--details-transition-speed, 150ms) linear;
  height: calc(1lh + (var(--calculated-details-padding) * 2));
  padding: var(--calculated-details-padding);
  background: var(--details-bg, white);
  color: var(--details-color, currentColor);
}

details[open] {
  height: auto;
  overflow: clip;
}

Native libraries are hard in Rust; the compiler offers no guarantees about the memory representation of structs; or these structs needs to be FFI-Friendly with unsafe extern "C". There is no sandboxing, so a malicious code could promise the machine; or corrupt the memory silently.
Finally, dynamic library plugins are distributed as compiled code.It's easier to hide backdoors in compiled code. It's also harder to share the code than simple scripts.

There are two main ways to embed JavaScript in a Rust program. The first one is with bindings for the lightweight QuickJS engine, such as rquickjs. Take a look at AWS' LLRT (Low Latency Runtime) for an advanced integration of QuickJS in Rust.

Ho, and did I mention that QuickJS is lightweight? Around 210 KiB of code vs around 40 MiB of code for V8, all while being fast enough for most situations.

My vision of programming is to limit ourselves to two programming languages. A very powerful, secure and fast compiled language for the lower levels of the computing stack, Rust, and a less powerful and slower scripting language for high-level scripting and user interfaces, JavaScript.

Another alternative is WASM. The provided code is already compiled; and the author judges the ecosystem too immature.

The last method is the less powerful: expression engine. It allows to specify a language with some rules, even if it is not turing complete and the result always evaluate to an expression.

So to rank them:

• scripting language
• expression engine
• WASM
• at the end native libraries

The language can catch subtle errors for large codebases

If the maximum font size is less than or equal to 2.5 times the minimum font size, then the text will always pass WCAG SC 1.4.4, at least on all modern browsers.

The author also cites https://utopia.fyi/type/calculator/

How to load font the most efficient way in 2025 for nearly every cases.

To keep the code maintainable, keep the css specificity as low as possible.

BEM falls short: class names can get really long; reusability might not be prioritized; and things must be named.

Another case is to use utility classes (atomic css) to avoid css specificity.

A new approach is with cascade layers.

Anyways, Cascade Layers (@layers) groups styles and declares what order the groups should be, regardless of the specificity scores of those rules.

Each has a sweet spot:

• BEM for clear design system that needs to be consistent; team with different philosophies; styles are less likely to leak between components.
• utility classes: build fast, like prototypes or MVPs and component based JS framework
• cascade layers: legacy codebases where you need full specificity control; integrate third party libraries or styles from other sources; working on a large, complex application or projects with long-term maintenance

How they can work together?
The cascade layers can be seen as an orchestrator: one layer for components (BEM); one layer for utilities (utility classes)

While the CSS specificity is low, everything else is kept simple.

Only up the specificity lightly, and note it; the minimum is another class, :where() or the HTML tag.

A single class ".override" can also be used; but "If you’re ever overriding an override, that’s a good place to stop and re-consider. "

Instead of specifying Block or Element specific Modifiers, you create generic semantic classes that apply those repeatable styles to any element that needs them.

When I started creating Kelp, I went down the BEM path. I quickly switched to semantic CSS, and the file size decreased dramatically as a result.

After programming for years, I find creating a class system is better than BEM.