Today, if we want to use the new viewport units we have to duplicate declarations, and we still have to watch for the support of some font-dependent units, like “rem” also. Also, new units will come – we hope - and we’ll always have to deal with backward compatibility.
What if we could just create a stack of fallback units and values, in the same way we have for font-family?
For example, we could adjust spacement or font-sizes until the most “reliable” unit, pixels:
This sort of syntax doesn’t work generally. You can’t use commas, spaces, or slashes as the delimiter for fallback here, as they’re all used by actual CSS properties to separate their normal values.
Also, if one type of length isn’t supported, you might need to use a more different approach than just swapping in another length. CSS’s fallback mechanism was built specifically to handle this gracefully, as you can make whatever changes you need when you duplicate the property. (Or if you need to change more than just the one property, the newly-supported @support rule can be used to do fallback on entire groups of rules.)
I notice, though, that your ‘margin’ example isn’t even doing a super-local fallback; it’s still providing a completely new value for the entire property (either uses “1vh 1vw” or “20%”, whichever the UA understands). This is barely saving any keystrokes at all; it just avoids you having to repeat the property name itself. That’s almost certainly not worth adding new syntax for.
But a hyper-local fallback mechanism that can fallback a single value might be worthwhile, like:
Hi, Tab
Thanks for the reply. I’ve probably should give it more thought. The goal wasn’t exactly to save keystrokes, but to centralize (in one and only property) possible fallbacks.
My idea was indeed to create different value declarations, separated by coma, and the UA would get the first “understandable” one. I’m not aware of the contraints we may have in defining CSS syntax, so simple comas seemed to me enough. In this case, a fallback() options would be interesting indeed (though more verbose).
Why would it only be known at computed-value time? I mean, if you have variables involved, yes, you have to wait, but otherwise you should be able to know which one to use at parse time.
Sure, I was imagining the worst case, but you are right that it doesn’t actually adds up to the delay effect of variables, it is jus the delay effect of variables.
What I meant is that
property: var(v1);
property: var(v2);
and
property: firstOf(var(v2), var(v1));
are actually different.
Also, firstOf can require combinatorial attempt:
property: firstOf(a, b) firstOf(c, d);
// only valid may be "b d" or "a d"