- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 18 Dec 2015 14:57:14 +0100
- To: "Philip Walton" <philip@philipwalton.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Chris Lilley" <chris@w3.org>
- Cc: "www-style list" <www-style@w3.org>
On Fri, 18 Dec 2015 13:39:51 +0100, Chris Lilley <chris@w3.org> wrote: > Hello Simon, > > Friday, December 18, 2015, 12:05:53 PM, you wrote: > >> But it seems to me you're only likely to want it for var(). Since this >> appears to be a pattern people use in the preprocessor world, should we >> just support it? It wouldn't be difficult to define a new -var(x) >> function >> as calc(-1 * var(x)), right? Too much of a hack? Slippery slope? > > Doesn't -var() mean either: > > a) the vendor-prefixed () for the var vendor, or > b) a parse error because the vendor prefix should end with a - as well > > otherwise, defining it as syntactic sugar for calc seems okay. Vendor prefix is -foo-bar, this is just -foo. It's not a parse error, it just gets dropped because -var() is unknown, like lolwut(). > But > then authors will expect to negate other functions in a similar way, > no? Yeah, that is a risk (hence "slippery slope"), but what other function would you want to negate, in practice? -- Simon Pieters Opera Software
Received on Friday, 18 December 2015 13:57:46 UTC