- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 21 Mar 2012 17:25:56 -0700
- To: www-style@w3.org
On 03/21/2012 02:25 PM, Tab Atkins Jr. wrote: > On Wed, Mar 21, 2012 at 1:17 AM, Simon Sapin<simon.sapin@kozea.fr> wrote: >> Le 21/03/2012 00:31, Tab Atkins Jr. a écrit : >>>>> [data-gravatar-uri]::after >>>>> { >>>>> content: url(attr(data-gravatar-uri)); /* impossible */ >>>>> } >>>>> >>>>> [data-email-md5]::after >>>>> { >>>>> content: url("http://www.gravatar.com/avatar/" >>>>> attr(data-email-md5) >>>>> "?s=100"); /* more impossible */ >>>>> } >>>>> >>>>> >>>>> [data-email-md5][data-gravatar-size]::after >>>>> { >>>>> content: url("http://www.gravatar.com/avatar/" >>>>> attr(data-email-md5) "?s=" >>>>> attr(data-gravatar-size) ); /* more& more impossible */ >>>>> } >>> >>> I support the use-case, but I dunno how to accomplish it. url() is >>> pretty much ruined; the fact that we didn't require it to contain a >>> quoted string originally pretty much prevents us from doing anything >>> useful inside of it. >> >> Wouldn’t image() work at least for the first case? >> >> Some spec change / new feature would be needed for the two other cases, but >> image() seems to have better chances than url() (which is parsed as a single >> token to allow omitting quotes) > > Yes, image() just takes a<url> or<string>, both of which attr() can return. > > I agree that any feature that ends up doing this kind of string concat > would be better done in image(), because it doesn't have all the > horrible legacy parsing around it. You might want to use it for things that aren't images, so I don't think it goes in image(). It probably does need a new function, though, rather than re-using url(). ~fantasai
Received on Thursday, 22 March 2012 00:26:23 UTC