• aspect-ratio
• padding-bottom depending of the aspect-ratio
• css variables, but one dimension needs to be known:

  --aspect-ratio: calc(4/3);
  --height: 30vmin;
  --width: calc(var(--height) * var(--aspect-ratio));
  height: var(--height);
  width: var(---width);

• all property: change heritance rule of all CSS properties
• currentColor : value of the element's current color property
• custom property fallback value
• counters
• interaction media queries: selector depending on the primary input mechanism — touch, stylus, mouse pointer, etc. Which is not what we have
• :where and :is pseudo-selectors:
• scroll-padding: add padding on scroll, for example for a top header :D
• isolation: isolate: create a new stacking context without relying on z-index magic numbers
• content-visibility and contain-instrinsic-size for render performance optimization

A typescript enumeration containing all http status codes

I totally agree and it felt natural to me

Memory and local storage are great for “private” state — settings, caches, history. URL parameters are good for the “public” state, so that one could bookmark or forward the stateful link.

I am already applying that, but only because I had a class about it. It is useful though to have content about it online.

Sadly does not work for casual users of Firefox at the moment (2022-06-03) as stated by caniuse.

EDIT 2024: it works now.

SQL table expressions are somewhat similar to functions in a regular programming language — they reduce the overall complexity.
You can write an unreadable sheet of code, or you can break the code into understandable individual functions and compose a program out of them.
You can build a tower of nested subqueries, or you can extract them into CTEs and reference from the main query.

There is a myth that “CTEs are slow”. It came from old versions of PostgreSQL (11 and earlier), which always materialized CTE — calculated the full result of a table expression and stored it until the end of the query.

Ok. There are some rules:

• CTE runs on every request
• CTE splits the query code into multiple chunks
• instead of subquery, always use CTE for clarity

With this it is possible to try SQLite in the browser. The whole thing runs using WASM (compiled using Emscripten) and was announced by Richard Hipp as part of the SQLite 3.39.0 beta in the SQLite forum.

What is also interesting is that to load the page, less than 1 MB of data needs to be loaded. If compression were enabled, this could probably be reduced further.

sqlite3 fiddle could make it easier to quickly try something with SQLite. Instead of downloading sqlite3 first and then trying it out locally, you just open the page and can quickly use the latest sqlite3 version.

(from https://jlelse.blog/links/2022/05/sqlite3-fiddle)

How to have temporary data:
1 - Common Table Expression (or basically a named subquery)
2 - View: works like a CTE, but you can reference it by name and not repeat the subquery every time. Views are computed on the fly, similar to CTEs.
3 - A temporary table is like a real table: it stores data on disk, and you can build indexes. But it exists only while the database connection is open.

PostgreSQL and others have materialized views, which store data on disk

When to use temporary tables ?

Temporary tables are great for experimenting when you’re just getting to know the data.

background-clip: padding-box to avoid overflow of the background if border-radius is set.

A good starting point

It seems so flat to me (i.e. all the elements are on the same grid), but I think the idea is good.

With this way of thinking:

• we remove cluttered divs
• HTML stands for content and semantic; CSS for display

Unit > Integration > E2E is still a valid pyramid for testing; but better can be found.

Static analysis > Unit + Integration > e2e

Static analysis means to check the code without running it. We already have examples with Eslint as a javascript code style fixer; Stylelint for CSS code fixing (I have to try); Sonarqube

Unit and integration tests are mixed together as:

• The definition of a unit is often “to be discussed”: If you ask a group of developers to define a unit, you will mostly get various, differing answers. As some refer to a function, class, or service — minor units — another developer will count in the complete component.
• In addition to those definition struggles, drawing a line between unit and integration can be tricky, as it’s very blurry. This struggle is real, especially for Frontend, as we often need the DOM to validate the test basis successfully.
• It’s usually possible to use the same tools and libraries to write both integration tests. So, we might be able to save resources by merging them.

There are also visual tests. We can group e2e-tests and visual tests into a UI test category. Btw the recommended open-source and fully self-hosted tool for visual testing is Visual Regression Tracker

As a general rule, we should give the user as much control as possible, and we should never disable or block their settings from working. For this reason, it's very important to use a relative unit like rem for typography.

Then we should use rem everywhere ?

Do I actually want everything to scale with font size?
When we use rem values for horizontal padding, though we amplify the effect "larger the text is, the fewer characters can fit on each line".

So the final question is:

“Should this value scale up as the user increases their browser's default font size?”

I've come to realize, however, that we usually do want to use rems for media queries.

We're so used to thinking of media queries in terms of mobile/tablet/desktop, but I think it's more helpful to think in terms of available space. [Why in the post]

Other example is the space between paragraphs: it has a "functional" purpose so that we can quickly tell where one paragraph ends and the next one begins. For this reason, it does make sense to scale these margins with the user's chosen root font size.

Example of use of em instead of rem

• rem

h1 {
  font-size: 3rem
  margin-top: 6rem;
  margin-bottom: 1.5rem;
}
h2 {
  font-size: 2rem
  margin-top: 4rem;
  margin-bottom: 1rem;
}
h3 {
  font-size: 1.5rem;
  margin-top: 3rem;
  margin-bottom: 0.75rem;
}

• em

h1 {
  font-size: 3rem;
}
h2 {
  font-size: 2rem;
}
h3 {
  font-size: 1.5rem;
}
h1, h2, h3 {
  margin-top: 2em;
  margin-bottom: 0.5em;
}

Another example is the width of a button: we can think about it alone yet.

Finally, it is better to forge an intuition as opposed to a set of rules about using rem/px as there are always edge cases.

A framework for building a web app in Rust 🤔
May be useful someday.

It's true that the Rust ecosystem is growing and tools are coming. But we lack the knowledge of how we can put things together. Here it fills the gap.

Drawing a cube in css and webgl... it turns out it is easier in CSS

Python support also unicode caracters, so you can write a 𝝨(...args) function :D

Some smooth checkboxes :)

I am using this trick to animate checkboxes, but I have to check it out for master it !