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

Re: [css-variables] whether implied tokens due to EOF are included in variable value

From: Simon Sapin <simon.sapin@exyr.org>
Date: Mon, 20 May 2013 23:13:46 +0800
Message-ID: <519A3DAA.6070808@exyr.org>
To: Cameron McCormack <cam@mcc.id.au>
CC: www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Le 20/05/2013 16:36, Cameron McCormack a écrit :
> Say you have this:
>
>     <style>#a { var-x: ( url(http://example.org/</style>
>
> Is this variable declaration valid or is it dropped?  If it is valid, is
> the computed value of this property
>
>     1. "( url(http://example.org/))"
>     2. "( url(http://example.org/)" or
>     3. "( url(http://example.org/"
>
> ?  I think the answers should be "valid" and "1", but I don't think it
> is clear from the spec.

EOF is a valid way to implicitly close the () block:
http://www.w3.org/TR/CSS21/syndata.html#unexpected-eof

In Syntax 3 this rule is generalized to URL tokens, but in 2.1 I think 
this would give a BAD_URL token.

It isn’t clear to me either what would cause a declaration to be 
dropped. See:
http://lists.w3.org/Archives/Public/www-style/2013Apr/0312.html

As to the computed value, in my mental model a list of component values, 
as defined in css-syntax and css-values. In this case, it’s a whitespace 
token followed by a () block which contains a whitespace token followed 
by a URL or BAD_URL token.

Now, how this computed value is *serialized* into a string is a separate 
issue. Assuming a URL token rather than BAD_URL, I think it would be 1. 
because there is no reason to preserve the information that a () block 
was implicitly closed. But indeed, that is not specified either in what 
little we have spec’ed on serialization:
http://dev.w3.org/csswg/css-syntax/#serialization

Tab, is this section meant to be a normative definition of 
serialization? Should it (eventually) be referenced from CSSOM?

Cheers,
-- 
Simon Sapin
Received on Monday, 20 May 2013 15:14:18 UTC

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