Features in CSS?!

A much-needed disclaimer: You (kinda) can use features now! I do know, it isn’t probably the most nice feeling to complete studying a couple of new function only for the creator to say “And we’ll hopefully see it in a few years”. Fortunately, proper now you need to use an (incomplete) model of CSS features in Chrome Canary behind an experimental flag, though who is aware of once we’ll get to make use of them in a manufacturing setting.

Arguments, defaults, and returns!

I used to be ingesting espresso once I learn the information on Chrome prototyping features in CSS and… I didn’t spit it or something. I used to be excited, however thought “features” in CSS can be identical to mixins in Sass — you realize, patterns for establishing reusable patterns. That’s cool however is absolutely kind of syntactic sugar for writing much less CSS.

However I appeared on the instance snippet just a little extra carefully and that’s when the espresso practically got here capturing out my mouth.

From Bramus in Bluesky

Arguments?! Return values?! That’s price spitting my espresso out for! I needed to be taught extra about them, and fortunately, the spec is clearly written, which you could find proper right here. What’s crazier, you need to use features proper now in Chrome Canary! So, after studying and enjoying round, listed here are my key insights on what you have to learn about CSS Features.

What precisely is a perform in CSS?

I like this definition from the spec:

Customized features permit authors the identical energy as {custom} properties, however parameterized

They’re utilized in the identical locations you’d use a {custom} property, however features return various things relying on the argument we go. The syntax for probably the most primary perform is the @perform at-rule, adopted by the title of the perform as a <dashed-ident> + ()

@perform --dashed-border() {
 /* ... */
}

A perform with out arguments is sort of a {custom} property, so meh… To make them practical we are able to go arguments contained in the parenthesis, additionally as <dashed-ident>s

@perform --dashed-border(--color) {
 /* ... */
}

We are able to use the outcome descriptor to return one thing primarily based on our argument:

@perform --dashed-border(--color) {
   outcome: 2px dashed var(--color);
}

div {
   border: --dashed-border(blue); /* 2px dashed blue */
}

We are able to even use defaults! Simply write a colon (:) adopted by the default worth for that argument.

@perform --dashed-border(--color: crimson) {
   outcome: 2px dashed var(--color);
}

div {
  border: --dashed-border(); /* 2px dashed crimson */
}

CodePen Embed Fallback

This jogs my memory of Adam Argyle’s experiment on a practical CSS idea.

Features can have type-checking

Features can have type-checking for arguments and return values, which will likely be helpful at any time when we need to interpolate a worth identical to we do with variables created with @property, and as soon as we’ve got inline conditionals, to make completely different calculations relying on the argument kind.

So as to add argument varieties, we go a syntax part. That’s the kind enclosed in angle brackets, the place coloration is <coloration> and size is <size>, simply to call a pair. There are additionally syntax multipliers like plus (+) to just accept a space-separated checklist of that kind.

@perform --custom-spacing(--a <size>) { /* ... */ } /* e.g. 10px */
@perform --custom-background(--b <coloration>) { /* ... */ } /* e.g. hsl(50%, 30% 50%) */
@perform --custom-margin(--c <size>+) { /* ... */ } /* e.g. 10px 2rem 20px */

If as an alternative, we need to outline the kind of the return worth, we are able to write the returns key phrase adopted by the syntax part:

@perform --progression(--current, --total) returns <share> {
  outcome: calc(var(--current) / var(--total) * 100%);
}

Just a bit exception for varieties: if we need to settle for a couple of kind utilizing the syntax combinator (|), we’ll have to surround the kinds in a kind() wrapper perform:

@perform --wideness(--d kind(<quantity> | <share>)) { /* ... */ }

Features can have checklist arguments

Whereas it doesn’t at the moment appear to work in Canary, we’ll find a way sooner or later to take lists as arguments by enclosing them inside curly braces. So, this instance from the spec passes an inventory of values like {1px, 7px, 2px} and will get its most to carry out a sum.

@perform --max-plus-x(--list, --x) {
  outcome: calc(max(var(--list)) + var(--x));
}

div {
  width: --max-plus-x({ 1px, 7px, 2px }, 3px); /* 10px */
}

I ponder then, will or not it’s potential to pick a particular factor from an inventory? And likewise outline how lengthy ought to the checklist must be? Say we need to solely settle for lists that include 4 components, then choose every individually to carry out some calculation and return it. Many questions right here!

Early returns aren’t potential

That’s right, early returns aren’t potential. This isn’t one thing outlined within the spec that hasn’t been prototyped, however one thing that merely received’t be allowed. So, if we’ve got two returns, one enclosed early behind a @media or @helps at-rule and one exterior on the finish, the final outcome will all the time be returned:

@perform --suitable-font-size() {
  @media (width > 1000px) {
    outcome: 20px;
  }
  outcome: 16px; /* This all the time returns 16px */
}

We have now to alter the order of the returns, leaving the conditional outcome for final. This doesn’t make a variety of sense in different programming languages, the place the perform ends after returning one thing, however there’s a cause the C in CSS stands for Cascade: this order permits the conditional outcome to override the final outcome which could be very CSS-y is nature:

@perform --suitable-font-size() {
  outcome: 16px;

  @media (width > 1000px) {
    outcome: 20px;
  }
}

Imagining the chances

Right here I needed everybody to chip in and write concerning the new issues we might make utilizing features. So the crew right here at CSS-Methods put our heads collectively and considered some use circumstances for features. Some are little helper features we’ll sprinkle so much all through our CSS, whereas others open new potentialities. Keep in mind, all of those examples must be considered in Chrome Canary till assist expands to different browsers.

Right here’s a primary helper perform from Geoff that units fluid kind:

@perform --fluid-type(--font-min, --font-max) {
  outcome: clamp(var(--font-min), 4vw + 1rem, var(--font-max));
}

h2 {
  font-size: --fluid-type(24px, 36px);
}

This one is from Ryan, who’s setting the width with an intrinsic container perform — discover the default arguments.

@perform --intrinsic-container(--inline-margin: 1rem, --max-width: 60ch) {
  outcome: min(100% - var(--inline-margin), var(--max-width));
}

And take a look at this second helper perform from Ryan to create grid layouts:

@perform --layout-sidebar(--sidebar-width: 10ch) {
  outcome: 1fr;

  @media (width > 640px) {
    outcome: fit-content(var(--sidebar-width)) minmax(min(50vw, 30ch), 1fr);
  }
}

That is a kind of snippets I’m all the time grabbing from Steph Eckles’ smolcss web site, and having a perform can be a lot simpler. Truly, most of the snippets on Steph’s web site can be superior features.

CodePen Embed Fallback

This one is from moi. Once I made that demo utilizing tan(atan2()) to create viewport transitions, I used a helper property referred to as --wideness to get the display screen width as a decimal between 0 to 1. At that second, I wanted for a perform type of --wideness. As I described it again then:

You go a decrease and higher certain as pixels, and it’ll return a 0 to 1 worth relying on how huge the display screen is. So for instance, if the display screen is 800px, wideness(400px, 1200px) would return 0.5 because it’s the center level

I assumed I might by no means see it, however now I could make it myself! Utilizing that wideness perform, I can transfer a component by means of its offset-path because the display screen goes from 400px to 800px:

.marker {
  offset-path: path("M 5 5 m -4, 0 a 4,4 0 1,0 8,0 a 4,4 0 1,0 -8,0"); /* Round Orbit */
  offset-distance: calc(--wideness(400, 800) * 100%); /* strikes the factor when the display screen goes from 400px to 800px */
}

What’s lacking?

Based on Chrome’s problem on CSS Features, we’re in an excellent early stage since we can not:

• …use native variables. Though I attempted them and so they appear to work.
• …use recursive features (they crash!),
• …checklist arguments,
• …replace a perform and let the suitable kinds change,
• …use @perform in cascade layers, or within the CSS Object Mannequin (CSSOM),
• …use “the Iverson bracket features … so any @media queries or comparable will must be made utilizing helper {custom} properties (on :root or comparable).”

After studying what on earth an Iverson bracket is, I understood that we at the moment can’t have a return worth behind a @media or @assist rule. For instance, this snippet from the spec shouldn’t work:

@perform --suitable-font-size() {
  outcome: 16px;

  @media (width > 1000px) {
    outcome: 20px;
  }
} 

Though, upon testing, it looks as if it’s supported now. Nonetheless, we are able to use a provisional {custom} property and return it on the finish if it isn’t working for you:

@perform --suitable-font-size() {
  --size: 16px;

  @media (width > 600px) {
    --size: 20px;
  }

  outcome: var(--size);
}

What about mixins? Quickly, they’ll be right here. Based on the spec:

Right now, this specification solely defines {custom} features, which function on the stage of CSS values. It’s anticipated that it’s going to outline “mixins” later, that are features that function on the type rule stage.

In conclusion…

I say it with confidence: features will convey an unlimited change to CSS, not within the sense that we’ll write it any otherwise — we received’t use features to heart a <div>, however they may simplify hack-ish CSS and open so much of recent potentialities. There’ll be a time when our cyborg youngsters ask us from their training pods, “Is it true you guys didn’t have features in CSS?” And we’ll reply “No, Zeta-5 ∀umina™, we didn’t” whereas shedding a tear. And that may blow their ZetaPentium© Gen 31 Mind chips. That’s if CSS lasts lengthy sufficient, however within the meantime, I’m completely satisfied to alter my web site’s font with a perform.

---

Features in CSS?! initially revealed on CSS-Methods, which is a part of the DigitalOcean household. It is best to get the publication.