W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: CSS variable syntax

From: Mark Volkmann <r.mark.volkmann@gmail.com>
Date: Thu, 3 Apr 2014 14:31:41 -0500
Message-ID: <CAFfRWnUp2d7cCy79JSmG4kt5dghSrRchAiV5LhhUgs2Y19=ZWw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@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>
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.
Received on Thursday, 3 April 2014 19:32:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC