Re: [css-variables] ...let's change the syntax

16.03.2014, 00:57, "Cameron McCormack" <cam@mcc.id.au>:
> On 16/03/2014 3:28 am, Tab Atkins Jr. wrote:
>
>> šNo, we don't currently have that in any context, nor are there any
>> šcurrent plans for such. šIt would be *extremely* weird, since we don't
>> šuse -foo in the core language at all, and so any case where a "-" can
>> šbe put next to an ident-like token *already* requires a space between
>> šthem, to avoid the "-" being interpreted as part of the ident.
>>
>> šI'm potentially open to tweaking Syntax here (the fact that it's in CR
>> šis just a Process sop; we can continue to change as
>> šprudent/necessary), but as Simon says, this is a larger change than
>> šjust switching the naming pattern from one valid ident to another.
>> šI'll leave it to heycam to decide whether this is something that's
>> špossible to do within their shipping deadline or not.
>
> I don't forsee "--" as needing any changes to our CSS parser, so it
> shouldn't be any harder to switch to than "_".
>
> Despite Brian's retraction of the suggestion, I think using "--" is
> preferable to "_", on visual aesthetic grounds. šI also think it should
> be required as a prefix, not just a substring anywhere. šThat has the
> advantage of being easier to check in the parser, as well as enforcing
> some uniformity.
>
> ššp {
> šššš--company-color-1: green;
> ššššbackground-color: var(company-color-1);
> šš}
>
> looks fine to me. šUnderscores look very un-CSS-like.
>
> I don't have too much of an opinion on whether we should change custom
> property names from a "var-" prefix, but it does make sense to consider
> it, to align with the naming of other (future) custom things in CSS.

I like `--` prefix more than `_` prefix too.

`--` looks more consistent with current CSS syntax (and consistency with existing CSS syntax was originally one of the main reasons for using current syntax of CSS variables at all).

Also, as long as the main keynote of this thread is that custom properties are supposed not to be variables, `var()` should be renamed to something not variable-related.

`var()` may be replaced with `prop()` which argument can be limited to custom properties for now (with possibility to be extended to all properties in the future).

For example:

    p {
        --company-color-1: green;
        background-color: prop(--company-color-1);
    }

Note that `prop()` is supposed to be rather universal and its argument is entire property name, with custom-property prefix _not_ stripped off. This will allow to easily extend `prop()` to accept arbitrary property's name in the future.

Alternatively (or additionally to `prop()`), `custom()` CSS function can be used to retrieve a custom-property value:

    p {
        --company-color-1: green;
        background-color: custom(company-color-1);
    }

Note that `custom()` takes argument with prefix stripped off (like `var()` in the current spec draft).



By the way, it may make sense to reconsider using `$` character as both prefix and function name:

    p {
        $company-color-1: green;
        background-color: $(company-color-1);
    }

`$` does not explicitly mention `variable`, so the main keynote of this thread should be satisfied.

Note that using functional (with parentheses) notation of `$` for retrieving a value makes it possible to easily differentiate variable definition and usage which is good anyway. In particular, it will be potentially possible in the future to easily use such variables as property names (a feature not available for now, but potentially easily possible at syntax-level):

    .example {
        $bg: background-color;
        $(bg): #fff; /* Equivalent to `background-color: #fff` */
    }

And let's not forget that decisions made hurriedly are rarely good. So if the spec needs to be reworked, then it should be reworked (maybe even from scratch) in an unhurried manner.

Received on Saturday, 15 March 2014 22:04:01 UTC