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

A simple div and here's the result: beautiful design and pictures.

Some smooth checkboxes :)

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

calc is useless in min(), max() and clamp() functions

So much !

The way it is written is smart 👍‍

.hover-1 {
  --h: 1.2em;   

  line-height: var(--h);
  color: #0000;
  text-shadow: 
    0 calc(-1*var(--_t, 0em)) #000, 
    0 calc(var(--h) - var(--_t, 0em)) #1095c1;
  overflow: hidden;
  transition: .3s;
}
.hover-1:hover {
  --_t: var(--h);
}

One thing that is frustrating about searching for Tailwind stuff on the web is that because it’s the Hot Framework Of The Moment™, there’s a lot of garbage articles out there, jumping on the hype train.

Malediction of success

On this website, you can adjust the amount of CSS that you want :)

I’m saying: consider the options, weigh them up against the norm and test them out. As long as you have a good reason behind the implementation, it kind of doesn’t matter what others think.

Styles are based on the HTML tag. This library is small and can be reused very fast.

It seems better for small projects than TailwindCSS.

→ Remember: if your user is supposed to go somewhere, use an <a> element. If something with JavaScript needs to happen, use a <button> element.

I agree with that: link for navigation and button to trigger actions.

mask can hide part of the element is applied to.

It is a shorthand for all mask properties. I didn't find real example yet.

• trigonometric functions
• new viewport unites
• :focus-visible
• scroll-behavior can be smooth :)
• lazyloading images by default with an attribute
• html element to get a modal with all the accessibility stuff baked right in ([demo](https://codepen.io/una/pen/dyJRwvG))
• array.prototype.at supports negative integers

Breakpoint:   0       200px     400px     600px     800px     1000px    1200px    1400px       
               ├─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────>
 Slice:        ·   xxs        xs   ·    s    ·    m    ·    l    ·    xl       xxl       xxxl   
               ·                   ·         ·         ·         ·                              
               ·                   ·         ·  at(m)  ·         ·                              
               ·                   ·         ├────────┤·         ·                              
               ·                   ·         ·         ·         ·                              
               ·                   ·         · from(m) ·         ·                              
               ·                   ·         ├─────────────────────────────────────────────────>
               ·                   ·                   ·         ·                              
               ·                   ·            to(m)  ·         ·                              
               ├──────────────────────────────────────┤·         ·                              
                                   ·                             ·                              
                                   ·         between(s, l)       ·                              
                                   ├────────────────────────────┤·     

Using slice instead of pixel values makes it more comfortable. I am still using the mobile-first approach.

Another one to test. It looks ok though

• flexbox
• CSS grid
• CSS Custom properties
• Preference Queries
• Color changes
• Variable fonts
• Paths
• CSS filters
• Houdini
• Shadow DOM
• Native CSS modules

And coming: container queries, container units, native nesting, scoping, cascade layers, :has() selector, @scroll-timeline