Re: Proposal for adding variable declaration blocks

On Fri, Jul 18, 2008 at 3:57 PM, James Elmore <James.Elmore@cox.net> wrote:

>
>
>   The sigil will effectively
>> distinguish variables from keywords.  For comparison, other
>> implementations I'm aware of (PHP and bash, mainly) reserve no
>> variable names -- $function, $while, and so on are perfectly valid.
>> (Both do predefine certain variables before the program begins
>> executing, but those variables can generally be changed like any
>> other.)
>>
>> With the huge number of keywords CSS uses, it seems like a good idea
>> to avoid conflicts, as I remarked previously.  In some contexts,
>> $color would be a very reasonable choice for a variable name.  I don't
>> think you'd have to be an idiot at all.
>>
>
> Sorry for the poor example. My point was that using identical (except for a
> sigil, possibly) names lead to mental overlap and will eventually cause
> problems, based on my experiences. Perhaps others are smarter and can avoid
> these problems, but I find they almost always pop up.
>
> <style>
>    declare { $font: Times, New Times, serif; }
>    p { font: $font 12px blue; }
> </style>
>
> Maybe that points out the confusion better than 'color'. At any rate,
> overloading (the psychological term) causes mental fatigue and, if enough
> people are involved will trip someone up and cause problems which are harder
> to find than they need to be. I just prefer (personal preference, based on
> experiences I have no wish to repeat) that keywords be excluded.


Just jumping in real quick-like...

As noted by others, there is no way for an author (or anyone, really) to
tell what will become a keyword in the future, as CSS is constantly being
extended with new properties and keywords.  In other words, there *will* be
overlap no matter what we do, as someone will at some point write a
stylesheet with a particular variable name, and that same name will at some
point be incorporated into a new module spec.  We may be able to depend on
experienced authors rolling their own disambiguating prefixes, but not
everyone will do this, and it's really just passing effort onto authors that
can easily be done once in the spec.

So, regardless of the mental fatigue that it may cause to some people (I'm
not immune to the effect either), we can go ahead and purge our minds of
this concept.  We *must* allow reuse of keywords for simple
forward-compatibility reasons, and rely on the variable sigil to
disambiguate.


Francois Remy <fremycompany_pub@yahoo.fr> said:

> I don't like $varName. I much prefer var(varName);
> At the beginning I was for @varname but now, I've changed my stand of view.
>
> Here are two reasons I can find :
>
>   1. Extensibility of the model
>
> If we choose for var(varName), it will be possible later to add some other
> functions like :
>
>   var(oHeight + '5px')
> or
>   var(oWidth * 3)
> or
>   var('10%' - ('50px' * 2))
> or
>   color: var(iif(isDefined('tColor'), tColor, 'blue'))
> or
>   ...
>
> In this case, "var" will be a "variable expression" which can accept "css
> variables".
> Currently, "var" is only sending a pointer to a "css variable", but it can
> change in the future.
>

As Simetrical said (and you acknowledged), calc() already hits the use-cases
you listed.  Overall, though, your reasoning seems to be overloading the
var() syntax - it's no longer just a variable reference, but a general
calculator for *anything* variable (that is, anything not explicitly
predefined in CSS).  We have calc() for basic mathematical calculation now,
which addresses imo the vast majority of complex variability cases, and as
Simetrical also pointed out (and you also acknowledged), some calculation is
really better suited for a true programming language that has full support
for higher syntaxes, algorithms, and data structures already built in.  I
think we should just aim for the simple task of referencing a variable,
which (in addition to calc()) should hit very nearly all use cases.

With this simple goal in mind, I prefer the simple $ syntax.  Consider my
vote cast in its direction (and fwiw, I prefer it over =, for both aesthetic
and vague compatibility-related reasons).

~TJ