The @property
is totally new to me, but I see it’s headed to Chrome, so I suppose it’s good to know about!
There is a draft spec and an “intent to ship” document. The code from that document shows:
@property --my-property {
syntax: "<color>";
initial-value: green;
inherits: false;
}
We’ve got more information on all this now in our Complete Guide to Custom Properties.
That is the CSS exact-equivalent to a CSS.registerProperty()
, the JavaScript syntax for declaring CSS custom properties, also a new thing (under the Houdini umbrella, it seems).
It looks like you declare these not within a selector block, but outside (like a @media query), and once you have, you haven’t actually created a new custom property yet, you’ve just registered the fact that you probably will later. When you actually go to create/use the custom property, you create it within a selector block like you already do now.
The “commonly cited use-case” is pretty darn cool. Right now, this isn’t possible in CSS:
.el {
background: linear-gradient(white, black);
/* this transition won't work */
transition: 1s;
}
.el:hover {
background: linear-gradient(red, black);
}
You might think the white in that gradient will fade to red with that transition
, but no, that’s not transition-able in that way. If we needed this in the past, we’d resort to trickery like fading in a pseudo-element with the new gradient colors or transitioning the background-position
of a wider-than-the-element gradient to fake it.
Sounds like now we can…
@property --gradient-start {
syntax: "<color>";
initial-value: white;
inherits: false;
}
.el {
--gradient-start: white;
background: linear-gradient(var(--gradient-start), black);
transition: --gradient-start 1s;
}
.el:hover {
--gradient-start: red;
}
Presumably, that works now because we’ve told CSS that this custom property is a <color>
so it can be treated/animated like a color in away that wasn’t possible before.
Reminds me of how when we use the attr()
function to pull like data-size="22px"
off an element, we can’t actually use the <length>
22px, it’s just a string. But that maybe-someday we’ll get attr(data-size px);
I have no idea when @property
will actually be available, but looks like Chrome will ship first and there are positive signals from Safari and Firefox. 👍
Ok, if this transition is going to be possible if we do some custom magic, then why the hell won’t it be possible by default?
I could be wrong, but I believe it works like this: a gradient is a like a generated image, so currently it’s be akin to asking a browser to transition the background image from
white-black.jpg
tored-black.jpg
, which it can’t.As Christopher puts it, that’s exactly right. You are essentially transitioning a background-image, which isn’t possible
Animatable: no
under ‘Definition and Usage’Ok guys, I am aware that this is how the browser handle it. The question remains – why won’t it handle it better if we can use CSS to do that either way.
@Łukasz In the case of the custom property, what gets animated is the colour stop of the gradient, not the gradient image itself. To me, that means that the browser will recalculate a new image for each step of the transition.
I do understand what you are asking, mind you. Why can’t the browser currently create an image for each step? I think the answer is that it’s not supposed to read into each value (colour stop) of a gradient image, because you could be adding a colour stop (for example), preventing this behaviour — too much to interpolate, perhaps? That’s just my intuition, might be wrong; I haven’t read the spec in detail.
This is awesome. I remember reading about AmeliaBR’s proposal way back when. I’m excited to see it’s finally being implemented! It’s a small win but it will make a lot of authors’ lives easier, I reckon — all in one place.