RE: [css3-variables] Fallback vs. "invalid at computed-value time"

> From: simon.sapin@kozea.fr
>
> Le 24/02/2013 04:50, Tab Atkins Jr. a écrit :
> > Actually, going back to my "typing" idea in my previous message, we
> > can probably just invalidate the custom property itself, rather than
> > just make it define an invalid variable. That way, something like the
> > following would work (again, purely hypothetical syntax):
> >
> > var-bg: #333;
> > var-bg: conic-gradient(...) !type(image);
> > background: var(bg);
> >
> > Again, by declaring at parse time how the custom property should be
> > parsed, we can regain the benefits of the fallback mechanism.
>
> Hum, interesting. I guess that could work.

The reality check is however that it doesn't work very well. Consider:

    selector {
        var-index: 1;
    }
    
    selector {
        var-position: attr(data-js-computed-position);
        var-position: calc(3 * var(index)) !type(length);
    }

It's impossible to validate var-position at parse time. It would be possible if we would use SASS-like variables but as soon as the value of a variable depends on the object it's applied on (ie: dynamic), static checks at parse time are simply not possible.

Also, this trick is assuming that all values of a type are supported on all properties accepting the type, which may or may not be true. It wouldn't be completely surprising to allow conic-gradient as a valid image on 'background' but not on 'content' because it lacks intrinsic dimensions. The issue is certainly more obvious on properties that reject at parse time negative values (or non-integer numbers).

Anyway, when I came up with this problem, I was told to use @supports everytime I declare a variable whose value may depend on the browser engine. I guess that is the only true official respone you can get.

BTW, even that doesn't solve the cases where you want the value of a 'variable' to fallback on the value of another variable (since you can't check variable compatibility using @supports, and also because if any variable reference fails, the entire declaration is marked invalid at computation time, even if the invalid variable declaration happens only in a fallback value that would not be used.

    selector {
         background: var(bg1, var(bg2)); 
         /* not only buggy but also dangerous: 
            even if bg1 works, if bg2 fails 
            then the entire rule is dropped */
    }

A second issue that this 'declaration type' doesn't cover is the fallback value. Imagine that you want to fallback the fallback values, you can't do it properly with the current spec. Such sample would be:

    selector { 
         background: var(shadow-host button-background, green);
         background: var(shadow-host button-background, conic-gradient(...));
    }

I've always been for more effective checking of variables that enable @supports-less fallback mechanism and if you can get some more people actually consider this issue, that would be nice ^_^

http://fremycompany.com/TR/2012/ED-css-custom/#references-as-a-value

Received on Sunday, 24 February 2013 14:13:16 UTC