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.

Historically, the big limitation with CSS transitions has been that they only apply when a targeted CSS property changes from one value to another. If we want a property to animate when an element is created, we’ve needed to use CSS keyframe animations, like I’m doing in the example above.

The new @starting-style API is a workaround for this limitation. We can provide an alternative set of CSS declarations. When the element is created, it’ll immediately transition from these initial styles.

It's not handled the same way as keyframes though: when the @starting-style has a low specificity, it can be overwritten by other styles (that sets the CSS property to another value).

Solutions: nuclear (!important), CSS custom properties, using keyframes.

And keyframes seem to be only syntactic sugar.

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.

1) Top-Level Media Query
2) Nested Media Query
3) Variablizing the Columns
4) Using a Custom Function
5) Custom Function + if()

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!

The problem is annoying and difficult. Also secrets can be easy to rotate, can not rotate or ones that attackers use.

You could be doing so many good data security practices, like secure-by-design frameworks, database and field-level encryption, zero-touch production, access control… but logging bypasses all of that… and ultimately degrades trust, in your systems and in your company.

It happens to companies of all sizes: X, Google Cloud, Facebook

Causes:

1. Direct logging
2. Kitchen sinks: objects that contain or hold secrets, often in opaque or unexpected ways. Errors of requests are examples.
3. Configuration changes: turning logging level to debug.
4. Embedded secrets: a token shared by URL
5. Telemetry: error monitoring and analytics are logs. They often provide the local variable context.
6. User Input: the user provides wrong but PII data in a wrong field for example.

Fixes:

1. Data architecture:part of the solution is reducing the number of data flows and shrinking the problem space so you simply have less things to worry about and protect. One logging utility!
2. Data transformation: minimization, redaction, tokenization (and the trolls: hashing, encryption, masking)
3. Domain primitives: “combines secure constructs and value objects to define the smallest building block of a domain”. new Secret("..."). They provide security invariants and guarantees that basic string primitives simply cannot.
4. Compile-time: a logging function that never accepts secrets (TS branded types helps!)
5. Run-time classes (extends String): it identifies the secrets. Overwrite the toString() method in JS to return [redacted] but an explicit unwrap() method for example.
6. Read-once objects: they throw an error or [redacted] in case of second read.
7. Taint checking: the general idea here is that you add taint to various sources (like database objects), and yell loudly if the data flows into certain sinks (like logs). Demo: https://semgrep.dev/playground/s/4bq5L It's awesome and not awesome as the same time.
8. Log formatters: redact known dangerous property names
9. Unit tests
10. Sensitive data scanner
11. Sampling (every cases instead of proportions)
12. Log pre-processors such as Vector
13. People

Strategy:

1. Lay the foundation: Developing expectations, culture, and support is a must-have. Define what a secret is. Use structured logs to allow operations on them.
2. Understand the data flow: with the foundation laid, the next best thing to do is to understand and chart out how secrets flow through your system.
3. Protect at chokepoints: CI/CD and App code first, before relying on the loggging library and other operation services.
4. Apply defense-in-depth: data transformation, read-once objects, log formatters in the library, log pre-processors, sensitive scanners, people
5. Plan for response and recovery

(via https://sebsauvage.net/links/?LscYqg)

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