Re: CSS variable syntax

Thanks everyone for explaining this! Tab, I think you are correct that
these questions will be asked repeated. I suggest putting your answers on a
web page somewhere so you can just refer people to it.


On Thu, Apr 3, 2014 at 11:31 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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
>



-- 
R. Mark Volkmann
Object Computing, Inc.