Sieht das seltsam aus?
.element {
background: color(#eb8fa9 alpha(75%) blackness(20%));
}Das ist die „color function“ aus einer Entwurfspezifikation der CSS Working Group. Ich glaube, es geht darum, Farben einfacher und intuitiver handhabbar zu machen. Sieht für mich, der viel mit den Sass-Farbmanipulationsfunktionen arbeitet, großartig aus.
Tyler Gaw hat ein cooles Tool dafür gemacht
Ich sehe in der Spezifikation, dass es sich hier eigentlich um color-mod() handelt, nicht um color(). Wahrscheinlich hat es sich geändert, da ich einige Artikel und Plugins sehe, die darüber als color() sprechen.
Das ist die Gefahr, wenn man versucht, zukünftiges CSS mit den exakten Namen zu polyfillen, von denen man glaubt, dass sie verwendet werden. Wenn man richtig liegt, kann man es hoffentlich eines Tages entfernen und alles ist gut. Wenn man falsch liegt, kann man es nie wieder loswerden, weil der verbleibende Code nicht funktioniert (es sei denn, man schreibt ihn um). Man hofft auch, dass das Polyfill so geschrieben ist, dass es stattdessen die neue Syntax nutzt, anstatt sie nur in eine ältere Syntax zu verarbeiten. Ich bevorzuge lieber bewusst anders benannte Abstraktionen.
Danke fürs Posten, Chris!
Du hast Recht, die Benennung – und Syntax – der Farbfunktion ist noch im Fluss. Die aktuellsten Informationen, die ich dazu gefunden habe, sind diese Issue: https://github.com/w3c/csswg-drafts/issues/813
Ich bin mir also auch nicht zu 100 % sicher, ob „color“ oder „color-mod“ beabsichtigt ist. Die Beispiele in der Entwurfsspezifikation verwenden immer noch „color“. TBD scheint angebracht.
Eine coole Sache daran ist, dass ColorMe heute dieses Paket verwendet: https://github.com/ianstormtaylor/css-color-function zum Konvertieren der Farbfunktionsstrings in rgb(a)-Strings. Wenn sich also der Name in der Spezifikation ändert, kann dieses Plugin aktualisiert werden, um dies widerzuspiegeln und als neue Version veröffentlicht zu werden.
Du hast auch Recht, es gibt eine Gefahr. Es sind definitiv noch frühe Tage. Was ich gut finde, ist, dass diese Änderungen nicht in Browsern stattfinden. Da wir mit JS-Abstraktionen arbeiten, die zu heute funktionierendem CSS transpilieren, können wir experimentieren und spielen, um zu sehen, ob die vorgeschlagenen Features das sind, was wir wollen. Und hoffentlich ohne eine Menge schwer zu entfernender Altlasten in den CSS-Implementierungen von Browsern wie alternative Syntaxen und Vendor-Präfixe hinzuzufügen.
Wenn sich das ändert, werde ich versuchen, die Schritte, die ich mit ColorMe und ähnlichem mache, zu dokumentieren. Wird gut für die Nachwelt sein.
Ich verwende css-color-function auch sehr gerne mit einem CSS-in-JS-Ansatz (styled-components).
In Zukunft erwarte ich einfach ein Finden & Ersetzen
`${color()}` -> color()… und fertig!
Eingereicht: https://github.com/w3c/csswg-drafts/issues/868
„Ich bevorzuge lieber bewusst anders benannte Abstraktionen“
Wenn du Sass-Farbfunktionen magst, schau dir unbedingt SassMe an. Es macht das, was ColorMe tut, nur in Sass: http://jim-nielsen.com/sassme
Genial! Als jemand, der den Überblick über schließende Klammern verliert, ist das großartig!
Die CSS4-Farbfunktionen sind großartig, aber ehrlich gesagt verwirrend. Ich habe mir ein
Cheatsheet erstellt, um technisch zu verstehen, was vor sich geht.
Und was ist mit der Performance? Ein Hauptvorteil der Verwendung von CSS-Präprozessorfunktionen ist, dass sie nur einmal und nicht auf der Clientseite berechnet werden.
Ich frage mich, ob CSS4+-Funktionen jemals so wortreich und stark genutzt werden, dass sie sich negativ auf die Seiten-/Ladezeiten auswirken.