W3C home > Mailing lists > Public > www-style@w3.org > August 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 26 Aug 2013 09:28:55 -0700
Message-ID: <CAAWBYDBvg97F4dpCrg7ggSb83Pt+27MD5Oy3rvf1UbTF68no5w@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC