- From: Linss, Peter <peter.linss@hp.com>
- Date: Fri, 11 Feb 2011 03:10:48 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: www-style list <www-style@w3.org>
On 2/10/11 5:53 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >On Thu, Feb 10, 2011 at 5:34 PM, Daniel Glazman ><daniel.glazman@disruptive-innovations.com> wrote: >> Le 11/02/11 02:15, Linss, Peter a écrit : >> >>> Don¹t forget this case: >>> @var $foo /*this_is_a_valid_url*/; p { content: url($foo); } >>> >>> Is it a comment or not? >> >> >> Never. A comment is explicitely said to be able to happen anywhere >> between tokens in the grammar and you can almost consider it's >> stripped before tokenization (even if of course it is not). >> >> The variable assignment above is always reduced to @var $foo ; > >Exactly. Which is a parse-time error anyway, making the declaration >invalid. Invalid declaration or variable with an invalid (or null) value? IOW, does a @var object show up in the CSSOM for the stylesheet that could have a value assigned later? Also note that: @var $foo /*something*/else; p { content: url($foo); } would be perfectly valid, but would evaluate to: p { content: url(else); } while authors may very well expect to get: p { content: url(/*something*/else); } which is a valid url: "/*something*/else". At the very least, you should add a note stating that values for variables intended to be used inside url() should be quoted strings. ----- Actually, strike that. I forgot that $ is perfectly legal inside a url, so: p { content: url($foo); } Should NOT expand the variable, as it should be seen as a single url() token with the url value of "$foo". "(" and ")" are also legal inside a url, so: p { content: url(var(foo)); } would be a url with the value "var(foo)", not the expansion of $foo either. So add a note that variables don't work at all inside url(). You'd need to use: @var $foo url(...); Unless you want to come up with another variable syntax that isn't legal in a url (but probably best not to).
Received on Friday, 11 February 2011 03:12:01 UTC