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

On Sun, Feb 24, 2013 at 6:12 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> 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).

(Tangent: there's no context-sensitivity for images.  The sizing
algorithm in Images works everywhere, because every property defines a
"default object size".)

Something that only accepted non-negative numbers wouldn't accept
something typed as "number" - it'd need a "positive-number" type.  Not
too hard.  (And all property names should be valid types as well, so
most of the time you can just use the name of the property you're
going to substitute the variable into.)


> 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 */
>     }

Incorrect.  From the spec: "If the variable named by the first
argument is valid, the variable's value is substituted as normal. If
it's invalid, and a <fallback> was provided, the <fallback> is
substituted instead. Otherwise, the variable is an invalid variable."

The fallback isn't even touched unless necessary.  An invalid "bg2"
variable won't have any effect as long as "bg1" is valid.

> 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 don't understand the problem here, nor your example since it uses an
unfamiliar syntax.

~TJ

Received on Sunday, 24 February 2013 19:04:51 UTC