Allow stack for fallback CSS units

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:

h1 { font-size: 5vw, 2em, 24px; margin: 1vh 1vw, 2%; }

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:

margin: fallback(1vw, 2%) fallback(1vh, 1.5%);

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).

At some point, I proposed to have things like this to deal with variables and graceful degradation:

background: firstOf(
    var(my-bg-as-zogmatic-gradient),  // futurist browser
    var(my-bg-as-radial-gradient),    // modern browser
    var(my-bg-as-image-gradient)      // old browser
);

At some point, I even proposed a full algebra (and it’s still stored somewhere in my mind!)

[EDIT] The point was that, unlike a simple syntactic check (multiple declarations), the value used for “firstOf” is only known at computed-time.

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"

Also, firstOf can require combinatorial attempt:

Ah, right, we disallowed that from happening with toggle() - it can only be the sole value in the property.

And how old browsers would handle the new syntax? (sorry if my question seems naive)

Until it’s understood, it’ll be invalid and cause the property to be dropped, like any other new feature.