-
It's true, tho… When a browser looks at your CSS, it attempts to parse every rule. That involves validating basic syntax, & also type-checking the values. color: blue? ✅ Looks good, keep it. color: miriam? ❌ Sounds fake, ditch it. color: 20px? ❌ Nice try. Invalid. TerribleMia/1367984773105217537Permalink On twitter.com
♻️ 9 Retweets ❤️ 49 Favorites Mood +10 🙂
-
We can do the same thing with math functions, because we know they only accept & output numbers: margin: calc(red + 1)? ❌ Can't do math on colors. color: calc(10 + 1)? ❌ Can't output numbers here. color: hsl(calc(10 + 1) 50% 50%)? ✅ Looks good!Permalink On twitter.com
-
So most rules can be thrown-out as "Invalid" at "Parse Time" – which allows us to filter-out problems & fallback to a supported value before moving on: a { color: blue; color: color(display-p3 0.05 0.36 0.63); } Don't understand P3? Try blue. Progressive enhancement!Permalink On twitter.com
-
Variables, tho… We can check the syntax at parse-time, but that's about it. They accept any value, output any value, & basically show up anywhere. No way to do type-checking until we're almost done computing all the final values. They become "invalid at computed value time"Permalink On twitter.com
-
And that's why "invalid" variables that Look Valid-Enough at parse-time can't fallback to a previous rule: a { --oops: ten; color: blue; color: var(--oops); } That's all good syntax, so move on. By the time our var fails, we've already thrown out the fallback.On twitter.com
-
Anything that has "Invalid at Computed Value Time" behavior will not be able to fallback in the way we normally expect. Instead, it's treated as "unset" – use the inherited value if there is one, otherwise the "initial" spec default. Not ideal, but it works in most cases.Permalink On twitter.com
-
TL;DR My name is NOT a valid color. But should it be, tho? 🤔 Don't worry, it is a valid as… - generated content ✅ - list-counters ✅ - custom property names ✅ - grid-lines or areas ✅ [miriam-start] 💅🏼 [miriam-end]Permalink On twitter.com