W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: CSS Variables Draft Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 11 Feb 2011 09:37:25 -0800
Message-ID: <AANLkTikWjD0604yxq1jLxDLNBVqVCygKO6zO466Ta9Yu@mail.gmail.com>
To: "Linss, Peter" <peter.linss@hp.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style list <www-style@w3.org>
2011/2/10 Linss, Peter <peter.linss@hp.com>:
> 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).

Note added.  No, I definitely don't want to make a special variable
syntax just for handling the contents of url functions.  ^_^

~TJ
Received on Friday, 11 February 2011 17:38:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT