A pure CSS form plugin

TL;DR Nearly 50% of HWB possible values tends to grey shades.

In both HWB & HSL colors, we can describe white and black and a full scale of grays using any hue we want. It doesn’t matter what hue we provide in either table

Lucky for us, browsers don’t generally render gradients using naive HSL math: currently browsers convert everything to sRGB before mixing. Gradients in RGB can still get muddy at times

Without auto, the remains 4 / 3, and the image appears stretched. You can avoid the stretching with object-fit:

img {
  aspect-ratio: 4 / 3;
  width: 100%;
  object-fit: cover;
}

Although, if the image isn't actually that aspect ratio, it'll either end up stretched (object-fit: fill), letter-boxed (object-fit: contain), or cropped (object-fit: cover). None of which are ideal.

Using clip-path to define custom shapes inside a container!
Percentages units has the benefit of keeping things responsive
There is many clip-path functions: inset, circle, ellipse, polygon and... path for maximum flexibility

clip-path: inset(x x x x) is useful for clipping blocks of an element and using it as a "controlled" overflow.
This clip-path value represents a thunderbolt: polygon(100% 0, 20% 50%, 35% 50%, 0% 100%, 70% 50%, 50% 50%)

We can transition or animate clip-path. There's one condition. The path must have a consistent structure. For example, if we transition a polygon, that polygon must have a consistent number of points.

Skewing effect: https://codepen.io/enbee81/pen/yLyrmyg

and cyberpunk buttons in CSS: https://jhey.dev/writing/css-cyberpunk-2077-buttons-taking-your-css-to-night-city/

Creating patterns for imgs

This size matches the dimensions of our SVG exports. This is important. This is the one drawback of using clip-path: path(). It's not responsive. The path definition is relative to the dimensions of your element.

Changing the shape:

.portrait {
  transition: clip-path 0.2s, transform 0.2s;
  transform: scale(var(--scale, 1)) rotate(var(--rotate, 0deg));
  clip-path: path(var(--clip, var(--splat)));
}
.portrait:hover {
  --scale: 1.15;
  --rotate: 30deg;
  --clip: var(--splattier);
}
.portrait:active {
  --scale: 0.85;
  --rotate: -10deg;
  --clip: var(--splatted);
}

This is the critical mental-model shift. CSS properties on their own are meaningless. It's up to the layout algorithm to define what they do, how they're used in the calculations.

Here's an example which blew my mind: Did you know that the width property is implemented differently depending on the layout algorithm?

I didn't know 😱

Inline space under images are due to the Flow layout and its inline elements. It adds extra-space to make sure that inline elements, such as <img />, don't negatively affect the legibility of the surrounding text.

There are a lot of layout algorithms in CSS, and they all have their own quirks and hidden mechanisms. When we focus on CSS properties, we're only seeing the tip of the iceberg. We never learn about really important concepts like stacking contexts or containing blocks or cascade origins!

Our intuition is the best tool we have. And when we start using CSS snippets without truly understanding them, it's only a matter of time until some hidden aspect of the layout algorithm throws a wrench into our gears, stopping us in our tracks.

.full-width {
  width: 100vw;
  margin-left: 50%;
  transform: translate3d(-50%, 0, 0);
}

Or a responsive approach with CSS grid:

.wrapper {
  display: grid;
  grid-template-columns:
    [full-start] 1fr [wrapper-start]
    minmax(0, 70rem) [wrapper-end] 1fr [full-end];

  /* Optional gap */
  column-gap: var(--pad, 1rem);
}

Then

.wrapper > * {
  grid-column: wrapper;
}

.wrapper > .full-width {
  grid-column: full;
}

Check for font-palette and @font-palette-values.

Only usable in Chrome and Safari for now :(

Generate a CSS grid easily

• 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

An example of clip-path to better understand how it works

Nice blob shapes for boxes :D

With another border-radius on hover and a transition: border-radius, it creates god damn cool effects.

A css only typewriter !

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

EDIT 2024: it works now.

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

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.