Re: [css-variables] Putting it all toegether (syntax)

On Mon, Jun 4, 2012 at 9:36 AM, François REMY <fremycompany_pub@yahoo.fr> wrote:
> 5.    Why we don’t want { $foo: bar }
>
> As noted by some users, this syntax is confusing; firstly because authors
> expect intuitively to be able to use preprocessor variables anywhere,
> including in selectors and to shorten property names. This means that “$foo:
> bar” can easily be confused as “the property name contained by the foo
> variable should be set to bar” instead of “the foo variable should be set to
> bar”.

I don't think this is valid.  If authors do labor under this
misconception, it will only be for the handful of moments until they
actually learn what it does.  There's no way to read even a trivial
amount of variable usage without seeing what's going on, so confusion
can persist no more than a few seconds.  ^_^

Further, we *can not ever* have property names determined by
variables, without drastically altering the way the cascade is
resolved.  Variables, as they are, already require some hacky handling
of properties whose values become invalid after variables are
substituted.  If we couldn't even figure out which properties were
being used until variable substitution time...

> Secondly, this is breaking the core CSS grammar which has been referenced as
> non-updatable by this working group several times. Reasons include
> incompatibility with tools and browsers. “html { $color: red; }” is for
> example understood as “html { color: red; }” by IE6 and IE7. Compatibility
> with existing tools is clearly something we should take care.

The Core Grammar is not frozen.  We can change it in ways that are
compatible with legacy content, just like we can do with every other
feature of the entire web platform.

The behavior of IE6 and IE7 is irrelevant here, unless content written
for their quirks, which was previously invalid but now would be made
valid, produces a bad result.  I've addressed this already - new sites
can avoid odd behavior in IE6/7 by avoiding the use of variables with
the same names as properties.

> Last but not least, this is hiding the property-like nature of CSS
> variables, which severely impairs the clarity and discoverability of the
> feature.

I'm not sure how having it look like a property hides the property-like nature.


> 6.    Why we need a prefix
>
> However, if we don’t use the $ prefix, we have to restrict the names authors
> can give to their user-defined properties. The reason is pretty clear: a CSS
> variable should never collide with a future framework-provided property. If
> variable names are constrained by a prefix, this becomes a no-brainer:
> future properties won't use that prefix.
>
> Based on my reflection, I initially coined the “x-” prefix (whic is a nice
> and short prefix for user-defined things) but Sylvain noted it’s being
> deprecated in the HTTP protocol. My current preference goes to a 'my-'
> prefix; however, a more consensual choice like “data-” is probably seen as
> more acceptable by the WG members, I don't know.
>
> [[Disgress: Actually, it’s to be noted that "data-" was the used prefix
> before the current draft and made consensus at the time in the CSS WG.
> However, the data() function led many to think this would be confused with
> HTML’s data attributes. This function being gone, I think we can remove that
> fear from our list and benefit from the name semantics. In fact, I think
> that the similarity of working between HTML’ data attributes and CSS
> variables can gain to be outlined.]]

The draft currently uses the "var-" prefix.  I think this is ideal for
naming purposes, if we decide not to tweak the Grammar, since they're
called "variables".  This also happens to match the nomenclature of JS
vars.


> 9.    Things I would like to highlight
>
> Here are important things I would like you to note about the proposal:
>
> -    The $ is not part of the property name: this is a replacement indicator
> token.
> This means that it can be reused for any future replacement behavior that
> may benefit from it: this is very future-proof.

I believe it better to attempt to adjust the Core Grammar to
accommodate the "same syntax in definition and usage" point.  If this
doesn't happen, we'll see.


> -    Variables are still properties like any other.
> In a future revision of the spec, we may allow things like $color (a value
> semantically equivalent to currentColor). There’s no reason a property could
> not reference the specified value of another property as long as no
> dependency circle is created. And we now have a solid resolution to apply in
> case such a dependency circle happens in practice.

There is a good reason to not allow properties to access the values of
other properties on the same element - properties can potentially
refer to other properties to define their values, creating an
*implicit* dependency that's harder to reason about than the explicit
dependency of a var referring to another var.  Additionally, these
dependencies can change and grow over time.  The existence of
currentColor already means that the 'color' property can't ever depend
on the value of any other property that can take a <color> without us
having to invoke something like what variables do for cycles.

However, there's nothing wrong with referencing the inherited value.
If we come up with decent use-cases, we can always extend parent-var()
to take an arbitrary property name (rather than just a variable
property name).

~TJ

Received on Monday, 4 June 2012 22:55:14 UTC