Re: [css-variables][css-conditional] bad-string and bad-url tokens in non-custom properties that reference variables

On Mon, Aug 26, 2013 at 2:22 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> Le 26/08/2013 07:58, Cameron McCormack a écrit :
>> <bad-string> and <bad-url> tokens are disallowed in <any-value>, which
>> is used as the value for custom properties and also as the fallback for
>> variable references.  But they are not disallowed at the top level of a
>> non-custom property that has variable references (and thus invokes the
>> "property value containing a variable must be assumed to be valid at
>> parse time" requirement).  So:
>>
>>     @supports (color: var(a, "
>>               ))                         { ... fails ... }
>>     @supports (color: var(a, url("b" c)) { ... fails ... }
>>     @supports (var-a: "
>>               )                          { ... fails ... }
>>     @supports (var-a: url("b" c))        { ... fails ... }
>>
>> But:
>>
>>     @supports (color: var(a) "
>>               )                          { ... succeeds ... }
>>     @supports (color: var(a) url("b" c)) { ... succeeds ... }
>>
>> Should we make these fail too?
>>
>
> Ah, interesting case. IMO we should change css-variables to make this
> invalid in all contexts (not just @supports.) That is:
>
>   Declarations with variables references do not have their value checked
> against the grammar of the property at parse time. Instead (this is the new
> part) the value must match <any-value>.

Yeah, this seems reasonable to me.  We don't want to spread
computed-time-invalid further than necessary if we really can tell
that something is invalid at parse time.

~TJ

Received on Monday, 26 August 2013 16:29:41 UTC