New CSS variables syntax in latest WebKit

[David Hyatt]

I've added support for several of the proposed syntax ideas for CSS  
variables to WebKit.  They are basically all co-existing side by side  
in WebKit right now.  The idea is for people to try out test cases to  
help get a feel for which syntax works best (or you can just proclaim  
which syntax you think is best right now without writing any tests at  
all). ;)

For the rules, the following syntax works:

(1)

@-webkit-variables { ... }
@-webkit-variables screen { ... }

(2)

@-webkit-define { ... }
@-webkit-define for screen { ... }

For variable references, the following syntax works:

(1) -webkit-var(foo)
(2) =foo=
(3) $foo

One concern about using a symbol to represent a variable is that there  
is no way to vendor-prefix it.  Then again, just using a symbol like =  
or $ looks nicer than the ugly "-webkit-var" notation.

dave
(hyatt@...)

[Tab Atkins Jr.]

On Fri, Jul 25, 2008 at 1:39 PM, David Hyatt <hyatt@...> wrote:

I've added support for several of the proposed syntax ideas for CSS variables to WebKit.  They are basically all co-existing side by side in WebKit right now.  The idea is for people to try out test cases to help get a feel for which syntax works best (or you can just proclaim which syntax you think is best right now without writing any tests at all). ;)

For the rules, the following syntax works:

(1)

@-webkit-variables { ... }
@-webkit-variables screen { ... }

(2)

@-webkit-define { ... }
@-webkit-define for screen { ... }

For variable references, the following syntax works:

(1) -webkit-var(foo)
(2) =foo=
(3) $foo

One concern about using a symbol to represent a variable is that there is no way to vendor-prefix it.  Then again, just using a symbol like = or $ looks nicer than the ugly "-webkit-var" notation.

dave
(hyatt@...)

 @-webkit-variables and @-webkit-define are identical in effect, just different names, right?  I haven't tested yet, but do these work intuitively within @media blocks in the current implementation?  If not, are they expected to?

Currently it appears that the variables syntax is only for single values, to be used in the normal manner where the variable dereferences into a keyword.  Is this correct?  If so, is it expected that there will be a syntax for assigning entire sets of values?

I'm not intending to stir up more of the discussions on these issues, merely to get the details clarified.  ^_^

~TJ

[David Hyatt]

On Jul 25, 2008, at 2:01 PM, Tab Atkins Jr. wrote:

>  @-webkit-variables and @-webkit-define are identical in effect,  
> just different names, right?

Right.

> I haven't tested yet, but do these work intuitively within @media  
> blocks in the current implementation?  If not, are they expected to?
>

No, they don't work in @media blocks.  At the moment variables must be  
defined at the top of a stylesheet (just after the @imports).  As with  
the @import rule, variables rules support media queries built in, e.g.,

@define for print { ... }
@variables print { ... }

instead of

@media print { @define { ... } }

If we want variables to work inside @media blocks, we'd basically have  
to relax the restriction that variables rules must be at the start of  
the stylesheet.  (There is no implementation hurdle to doing so...  
this basically just comes down to syntactic preference.)

> Currently it appears that the variables syntax is only for single  
> values, to be used in the normal manner where the variable  
> dereferences into a keyword.  Is this correct?  If so, is it  
> expected that there will be a syntax for assigning entire sets of  
> values?
>

There are ongoing discussions about this, but basically yes.

@define {
        simpleVariable: green;
        complicatedVariable {
                background-color: red;
                color: blue;
        }
}

div {
        color: =simpleVariable=;
        =complicatedVariable=;
}

(Substitute in whichever syntax you like best for variable  
references.) :)

dave

[brkemper]

On Jul 25, 2008, at 12:32 PM, David Hyatt wrote:

> No, they don't work in @media blocks.  At the moment variables must  
> be defined at the top of a stylesheet (just after the @imports). As  
> with the @import rule, variables rules support media queries built  
> in, e.g.,
>
> @define for print { ... }
> @variables print { ... }
>
> instead of
>
> @media print { @define { ... } }
>
> If we want variables to work inside @media blocks, we'd basically  
> have to relax the restriction that variables rules must be at the  
> start of the stylesheet.  (There is no implementation hurdle to  
> doing so... this basically just comes down to syntactic preference.)

David, thank you for giving this to us to play with. As for the  
restriction you mention, I don't see any real downside to relaxing  
that. Maybe others do, and can comment on that. If it only meant that  
variables could not be used until after they are defined in the serial  
reading of the CSS, I could live with that (which would make them into  
de facto constants, I think).

[Daniel Glazman]

David Hyatt wrote:

> (1) -webkit-var(foo)
> (2) =foo=
> (3) $foo
>
> One concern about using a symbol to represent a variable is that there
> is no way to vendor-prefix it.  Then again, just using a symbol like =
> or $ looks nicer than the ugly "-webkit-var" notation.

It also looks terribly more dangerous because some server modules
already use such syntax for macro expansion on the server's side...
Honestly, I think 2 and 3 are not a good idea.

</Daniel>

[David Hyatt]

On Aug 22, 2008, at 1:07 PM, Daniel Glazman wrote:

> David Hyatt wrote:
>
>> (1) -webkit-var(foo)
>> (2) =foo=
>> (3) $foo
>> One concern about using a symbol to represent a variable is that  
>> there is no way to vendor-prefix it.  Then again, just using a  
>> symbol like = or $ looks nicer than the ugly "-webkit-var" notation.
>
> It also looks terribly more dangerous because some server modules
> already use such syntax for macro expansion on the server's side...
> Honestly, I think 2 and 3 are not a good idea.

Just so people stop worrying, we won't be shipping CSS variables in  
Safari if the syntax is not hammered down.  I will disable the feature  
if no consensus has been reached regarding syntax.

dave
(hyatt@...)

[Brad Kemper-2]

On Aug 22, 2008, at 11:07 AM, Daniel Glazman <daniel.glazman@...
 > wrote:

>
> David Hyatt wrote:
>
>> (1) -webkit-var(foo)
>> (2) =foo=
>> (3) $foo
>> One concern about using a symbol to represent a variable is that  
>> there is no way to vendor-prefix it.  Then again, just using a  
>> symbol like = or $ looks nicer than the ugly "-webkit-var" notation.
>
> It also looks terribly more dangerous because some server modules
> already use such syntax for macro expansion on the server's side...
> Honestly, I think 2 and 3 are not a good idea.
>
> </Daniel>

They use the equal sign notation? I thought that was fairly unique  
(which was also one of the criticisms about it).

Even with the dollar sign, is macro expansion really that fragile?  
What if you want to represent a dollar amount in your HTML? Wouldn't  
you just escape the $ in both cases? Unexpanded macros would never  
make it into the final rendered css, right?

[David Hyatt]

We've already had a regression in WebKit from the $ syntax.  People  
make $ typos in stylesheets apparently. :(

I think the function syntax is the least likely to cause backwards  
compatibility issues.

dave

On Aug 22, 2008, at 2:39 PM, Brad Kemper wrote:

>
>
> On Aug 22, 2008, at 11:07 AM, Daniel Glazman <daniel.glazman@...
> > wrote:
>
>>
>> David Hyatt wrote:
>>
>>> (1) -webkit-var(foo)
>>> (2) =foo=
>>> (3) $foo
>>> One concern about using a symbol to represent a variable is that  
>>> there is no way to vendor-prefix it.  Then again, just using a  
>>> symbol like = or $ looks nicer than the ugly "-webkit-var" notation.
>>
>> It also looks terribly more dangerous because some server modules
>> already use such syntax for macro expansion on the server's side...
>> Honestly, I think 2 and 3 are not a good idea.
>>
>> </Daniel>
>
> They use the equal sign notation? I thought that was fairly unique  
> (which was also one of the criticisms about it).
>
> Even with the dollar sign, is macro expansion really that fragile?  
> What if you want to represent a dollar amount in your HTML? Wouldn't  
> you just escape the $ in both cases? Unexpanded macros would never  
> make it into the final rendered css, right?
>

[Brad Kemper-2]

You're saying Wekit is now responsible for author typos? With a typo  
the author will not get what they expected regardless of this proposal.

Sent from my iPhone

On Aug 22, 2008, at 12:46 PM, David Hyatt <hyatt@...> wrote:

> We've already had a regression in WebKit from the $ syntax.  People  
> make $ typos in stylesheets apparently. :(
>
> I think the function syntax is the least likely to cause backwards  
> compatibility issues.
>
> dave
>
> On Aug 22, 2008, at 2:39 PM, Brad Kemper wrote:
>
>>
>>
>> On Aug 22, 2008, at 11:07 AM, Daniel Glazman <daniel.glazman@...
>> > wrote:
>>
>>>
>>> David Hyatt wrote:
>>>
>>>> (1) -webkit-var(foo)
>>>> (2) =foo=
>>>> (3) $foo
>>>> One concern about using a symbol to represent a variable is that  
>>>> there is no way to vendor-prefix it.  Then again, just using a  
>>>> symbol like = or $ looks nicer than the ugly "-webkit-var"  
>>>> notation.
>>>
>>> It also looks terribly more dangerous because some server modules
>>> already use such syntax for macro expansion on the server's side...
>>> Honestly, I think 2 and 3 are not a good idea.
>>>
>>> </Daniel>
>>
>> They use the equal sign notation? I thought that was fairly unique  
>> (which was also one of the criticisms about it).
>>
>> Even with the dollar sign, is macro expansion really that fragile?  
>> What if you want to represent a dollar amount in your HTML?  
>> Wouldn't you just escape the $ in both cases? Unexpanded macros  
>> would never make it into the final rendered css, right?
>>
>

[David Hyatt]

We're responsible for recovering from typos in the same way other  
browsers do (and the way we used to before supporting CSS variables). :)

dave

On Aug 22, 2008, at 2:57 PM, Brad Kemper wrote:

> You're saying Wekit is now responsible for author typos? With a typo  
> the author will not get what they expected regardless of this  
> proposal.
>
> Sent from my iPhone
>
> On Aug 22, 2008, at 12:46 PM, David Hyatt <hyatt@...> wrote:
>
>> We've already had a regression in WebKit from the $ syntax.  People  
>> make $ typos in stylesheets apparently. :(
>>
>> I think the function syntax is the least likely to cause backwards  
>> compatibility issues.
>>
>> dave
>>
>> On Aug 22, 2008, at 2:39 PM, Brad Kemper wrote:
>>
>>>
>>>
>>> On Aug 22, 2008, at 11:07 AM, Daniel Glazman <daniel.glazman@...
>>> > wrote:
>>>
>>>>
>>>> David Hyatt wrote:
>>>>
>>>>> (1) -webkit-var(foo)
>>>>> (2) =foo=
>>>>> (3) $foo
>>>>> One concern about using a symbol to represent a variable is that  
>>>>> there is no way to vendor-prefix it.  Then again, just using a  
>>>>> symbol like = or $ looks nicer than the ugly "-webkit-var"  
>>>>> notation.
>>>>
>>>> It also looks terribly more dangerous because some server modules
>>>> already use such syntax for macro expansion on the server's side...
>>>> Honestly, I think 2 and 3 are not a good idea.
>>>>
>>>> </Daniel>
>>>
>>> They use the equal sign notation? I thought that was fairly unique  
>>> (which was also one of the criticisms about it).
>>>
>>> Even with the dollar sign, is macro expansion really that fragile?  
>>> What if you want to represent a dollar amount in your HTML?  
>>> Wouldn't you just escape the $ in both cases? Unexpanded macros  
>>> would never make it into the final rendered css, right?
>>>
>>

[mikewse]

[multi-reply]

David Hyatt wrote:
> I've added support for several of the proposed syntax ideas for CSS  
> variables to WebKit.

David, again a big thanks for working on this. This will be a great
and long-missed addition to CSS, whatever syntax and semantics that
"win" in the end.

> For the rules, the following syntax works:
> @-webkit-define { ... }

This would correspond to @define after being blessed by an official
w3 recommendation I guess. I quite like "define" as its name is
quite intuitive wrt its behaviour, and it avoids any overloaded
interpretations of what to expect from something named as variable.
(I quite like "CSS variables" as the name of the spec though, so I
guess I'm not 100% consistent there ;-)

> For variable references, the following syntax works:
>
> (1) -webkit-var(foo)
> (2) =foo=
> (3) $foo
>
> One concern about using a symbol to represent a variable is
> that there is no way to vendor-prefix it.

The ultimate goal is that these constructs become part of a w3c
recommendation, so for the "final" naming scheme we don't really
need to take vendor-prefixing in account, right?

***

David Hyatt wrote:

> @define for print { ... }
> @variables print { ... }
>
> instead of
>
> @media print { @define { ... } }
>
> If we want variables to work inside @media blocks, we'd
> basically have to relax the restriction that variables rules
> must be at the start of the stylesheet.  (There is no
> implementation hurdle to doing so...  
> this basically just comes down to syntactic preference.)

I think I would prefer both to have variables inside media
blocks and to be able to declare variables anywhere in the
file. As long as the semantics are straight-forward for
reference-before-definition scenarios I don't see any big
problems.
(But this is said with a lot of respect for things I may be
missing.)

***

Daniel Glazman wrote:

> > (1) -webkit-var(foo)
> > (2) =foo=
> > (3) $foo
> >
> > One concern about using a symbol to represent a variable
> > is that there is no way to vendor-prefix it.  Then again,
> > just using a symbol like = or $ looks nicer than the ugly
> > "-webkit-var" notation.
>
> It also looks terribly more dangerous because some server modules
> already use such syntax for macro expansion on the server's side...
> Honestly, I think 2 and 3 are not a good idea.

This problem certainly exists, but I'm not sure how much
attention we should give to it. I would prefer a short and
intuitive syntax like $ and would welcome that some kind of
"damage estimation" be performed for the most popular
alternatives.

That said, an observation is that WML is using $() for its
references so the server modules that serve WML may well not
use that for their own macros :-)... There may be other, better,
examples.

Best regards
Mike