More robust value fallback support

[rtsao]

Value fallbacks (i.e. multiple values for a single property) are useful.

Because order is not currently guaranteed, using value fallbacks with styletron will not be robust.

[menelike]

@rtsao Not sure if I understand "value fallbacks" right, if it means deterministic resolution, then robinweser/fela#165 might be interesting. A atomic CSS cache (like styletron's) could solve that issue particially.

[joeshub]

@menelike here's an example of a value fallback in CSS for fonts:

font-family: 'Roboto', arial, sans-serif;
I imagine in Styletron use case would be:

{
    fontFamily: ['Roboto', 'arial', 'sans-serif'],
}

although you end up with the last array element being used instead letting the browser fall back gracefully.

[skellyb]

It looks like injectStyle already supports an array of values, but instead of creating fallbacks, multiple classes are being created. It's not clear to me what the use case for this functionality would be, since order is unreliable.

Here's a real use-case I'm trying to support:

// set font-size to 8vw, falling back to 32px if browser doesn't support that unit type
{ fontSize: ['32px', '8vw']  }

Currently, that would create two classes. I'd like it create one, with two rules in the order declared, like so:

.a { font-size: 32px; font-size: 8vw; }

Would it be reasonable to change how arrays of values are being handled? If so, I'd be happy to help.

[frenic]

I could give this a shot.

[TxHawks]

I'm trying to understand if the use case requested by @skellyb ({ fontSize: ['32px', '8vw'] } --> .a { font-size: 32px; font-size: 8vw; }) is supported by #145, into which #133 was merged to.

If it is, it'd be nice to add this to the documentation in some way (Happy to do it myself, once I actually undersand how deterministic fallbacks work).

[grundmanise]

Did anyone succeed in providing fallback values? for example for a background css prop.