The parsers are different in JS, Python, Go and Java.

Number are not precise:

• MAX_SAFE_INTEGER limits the number. Twitter had to use an `id_str.
• decimal precision is unreliable (in JS) --> always use dedicated decimal types (Python’s Decimal, Java’s BigDecimal, JavaScript’s decimal libraries)
• UTF-8 encoding in JSON allow single unicode code points or composed ones. Use .normalize("NFC") for JS strings.
• the object key order should be alphabetically in JSON.
• Different languages handle absence of values (undefined, null or a missing property) differently.
• No time format is official, so it's always custom:

  {
  "iso_string": "2023-01-15T10:30:00.000Z",
  "unix_timestamp": 1673780200,
  "unix_milliseconds": 1673780200000,
  "date_only": "2023-01-15",
  "custom_format": "15/01/2023 10:30:00"
  }

• Different parsers fail differently on malformed JSON.

The twitter example is only one. There is also postgres that stores the format as JSON and JSONB (normalized).
MongoDB uses an extended JSON format.

Workarounds:

• Use Schema Validation!
• custom normalisation function#:~:text=Normalize%20Data%20Types%3A%20Ender%E2%80%99s%20Data%20Normalization%20Game)
• Tests! Numeric Precision Tests, Unicode and String Handling, Date and Time Consistency, Error Handling Uniformity, Cryptographic Consistency, Performance and Memory Behavior

A toolkit to bootstrap an application

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

With box-shadow and a reset for outline.

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.

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.

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!