#define MAKE_U32_FROM_TWO_U16(high, low) ( ((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF) )

If I want to develop fluid type calculations that adapt to local context, I’ll use em and cqi (container inline size) values. If I want my calculations to remain consistent across the entire page, I’ll use rem and vi (viewport inline size) calculations. In either case, I’ll define those values on body or other elements – so that 1rem always refers to the result of our initial negotiation, and doesn’t take on more complex meaning.

For spacing on the y-axis, the line-height (lh) unit is great or the rlh (root line-height). The x-axis can be handled with the vi or cqi units.

The right units for any situation are the ones that express most clearly what we mean – and sometimes what we mean requires a combination of units.

There’s no best unit, no best layout mode, and no best selector. When we use the entire language, we have more tools for clearly expressing our goals.

See Poetic CSS Architecture

A great summary

After 25 years, the zoom property will get a spec.

Zoom affects the box model compared to tranform: scale()

• 64-bit address space (not limited to 4GB anymore)
• multiple memories
• garbage collection
• typed references
• tail calls (optimisation)
• exception handling
• relaxed vector instructions (?)
• deterministic profile (?)
• custom annotation syntax (?)

To show scrollbars only when they’re needed (while keeping space for the scrollbar if it’s added later) use the scrollbar-gutter CSS property: https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter

Note it's baseline 2024, so it's useful to hide it behind the @supports media query.

A janky scroll animation on focus can be solved with overflow: clip

The latest CSS features, similar to What you need to know about modern CSS (2025 edition) from Frontend Masters

Note animations does not work on Firefox.

Fix the overflow on hover correctly

Another post about type branding.

Raw HTML and CSS?

1. It's fast
2. It's easy
3. Pure HTML is evergreen
4. I can host it anywhere, often for free
5. Accessibility and SEO benefits are automatic
6. It won’t need security patches
7. There are no build steps

I totally agree: using HTML as much as possible, then CSS, then JS to enhance it in this order.

The API can respond with HTML fragments anyway for an HTML table.

Seach content in collapsible sections.

That's great!

Create a CA locally and use it to generate certificates. So it's perfect for local network requests (https, etc...)

About ?page=1 that can become /?page=1 OR 1=1

KISS for maintainability: "Nothing in Rust forces us to get fancy. You can write straightforward code in Rust just like in any other language. But in code reviews, I often see people trying to outsmart themselves and stumble over their own shoelaces. They use all the advanced features at their disposal without thinking much about maintainability."

Here an real life example.

But if simplicity is so obviously “better,” why isn’t it the norm? Because achieving simplicity is hard!

Even in Rust: abstractions are never zero cost for developers.

Often, simple code can be optimized by the compiler more easily and runs faster on CPUs. That’s because CPUs are optimized for basic data structures and predictable access patterns. And parallelizing work is also easier when that is the case. All of that works in our favor when our code is simple.

Most of the code you’ll write for companies will be application code, not library code. That’s because most companies don’t make money writing libraries, but business logic. There’s no need to get fancy here. Application code should be straightforward to keep your fellow developers in mind.

Tips:

• start small
• avoid optimization early
• delay refactoring: we have limited information at the time of writing our first prototype.
• write code for humans
• The right abstractions guide you to do the right thing

Similar to tailwind, but somehow better?