• 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

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.

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

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.

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

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.

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

Some smooth checkboxes :)

As Vue 3 classes are contained in attrs, we sometimes want to pass every prop attribute to the child, except the class attribute:
v-bind="{ ...attrs, class: undefined }"