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

13.03.2014, 07:39, "Tab Atkins Jr." <>:
> Simultaneously, I'm wrestling with the fact that basically nobody
> understands that one of the primary use-cases of Custom Properties is
> to do CSS polyfills, where you write your own properties with a "var-"
> prefix and interpret them with JS. šThis avoids the "have to re-parse
> the whole stylesheet yourself, and woe unto you if it's cross-origin"
> problem that today's CSS polyfills have. šFrom what I can tell, it's
> the "var-" prefix that's misleading everyone - it's *so* closely tied
> to var(), mentally, that it prevents people from imagining any other
> use.
> Given that "tie it to var()" was one of my explicit justifications for
> sticking with the "var-" prefix, I'm very aware of how much I've
> hoisted myself by my own petard.
> So, suggestion. šAssuming that we're sticking with the underscore
> thing for custom MQs/pseudo-classes/etc, I think we should move the
> syntax of Custom Properties to "any ident starting with/containing an
> underscore" as well. šThis'll tie the syntax more closely to the
> *other* "custom" things, which hopefully will lead to it being more
> obvious that this is literally a CUSTOM PROPERTY, not just a variable
> definition.

Reasoning looks weak.

Those interested in polyfilling (and capable to write a polyfill) are themselves able (regardless of exact syntax of custom CSS properties) to easily recognize custom properties as a workaround way to avoid pure-script reparsing of entire stylesheet.

As for the purpose of polyfilling itself, I'm still strongly convinced that _any_ (ANY) property should be easily accessible via JS _regardless_ of whether the property is standard or custom. So it should equally be possible to get specified value of `background-image`, or `my-super-custom-property`, or any other property. See my proposal of 2011-09-18:

Using custom properties for polyfilling (while, of course, better than _nothing_) forces web developer to _duplicate_ value in both standard property _and_ a custom one. Such duplication is totally not the same as "just _adding_ a small prefix to property name" as Tab likes to incorrectly advertise.

Anyway, if to choose between solely the two options -- "start with _" or "contain _" -- as a custom property indicator, I tend to prefer the first one.

> The var() syntax is unchanged - the argument just switches to being
> literally the property name, rather than the property name minus the
> prefix.

Using `var()` for accessing something that is not a variable looks confusing and therefore undesirable. Something like `prop()` would probably be more appropriate and intuitive. (And `prop()` should work for any property -- not just custom ones. ;-)

Received on Thursday, 13 March 2014 21:18:17 UTC