- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 3 Apr 2014 09:31:21 -0700
- To: Mark Volkmann <r.mark.volkmann@gmail.com>
- Cc: Chris Eppstein <chris@eppsteins.net>, Simon Sapin <simon.sapin@exyr.org>, "Jens O. Meiert" <jens@meiert.com>, W3C WWW Style <www-style@w3.org>
On Thu, Apr 3, 2014 at 9:11 AM, Mark Volkmann <r.mark.volkmann@gmail.com> wrote: > I'm not familiar with what @ is being used for. Why couldn't variables start > with @? @ is for at-rules. CSS Syntax already allows at-rules inside of style rules (none are defined yet, but it's available when we extend into that realm, which we will definitely do), and you don't need a semicolon between a property and a following at-rule, so we can't use at-keywords as value syntax. > Why would it be difficult to implement this so that --foo in a property > value means get the value of the foo property, making var(--foo) > unnecessary? I've explained my reasoning for this in a few threads, but I'm probably fated to repeat it multiple times. ^_^ There are several reasons. 1. A bare ident, even one that looks as distinctive as --foo, still isn't a very obvious marker that Something Is Happening. Variables do *weird* things to syntax ("--foo: 5px, blue; box-shadow: red 5px var() 10px 10px;" is valid, for example), and we want to make it *as obvious as humanly possible* that there's something funky going on. Functions seem to be much more visible, and so fit this purpose well. 2. Regardless of whether we allow --foo as a bare ident to refer the value of the --foo property, we'll still want a var() function as well, to allow things like fallback (already specified in the spec) and future extensions we'll allow. Allowing two syntaxes for the same thing produces confusion overall; we try to avoid it unless there's a very good reason. So, it's preferable to stick with the single syntax that we already know we'll need - the var() function. 3. CSS already allows "custom idents" in a few places, and more will show up in the future. Custom idents allow authors to specify *any* ident, which means that, for example, they'd be able to specify "--foo" as a counter style name via @counter-style, or a font face name via @font-face. Now, we do put some constraints on the syntax of custom idents already (there are a few values they're not allowed to have), but they're all of the "this small list of single keywords is verboten", which is easy to remember. Excluding the custom property name syntax from custom idents as well moves it into the "this pattern is verboten", which is harder to remember and understand. As much as possible, we try to avoid adding more fiddly details to syntax validity. ~TJ
Received on Thursday, 3 April 2014 16:32:08 UTC