Re: [css-variables] Why so inefficient?

I agree with Patrick here. I am recalling Lea's ideology that if we do
this, we make simple cases complex instead what we should be doing is make
the simple cases simple and complex cases possible.

It feels weirder because programmers aren't used to declaring/using
variables or equivalent programming language features in a method form.

My only concern is the <custom-ident> rules which theoretically allows them
to have "--". I wonder if we could restrict <custom-ident> to not have that.

On Sun, Feb 21, 2016 at 11:40 PM, Patrick Dark <
www-style.at.w3.org@patrick.dark.name> wrote:

> On 2/16/2016 5:35 PM, Tab Atkins Jr. wrote:
>
>> On Wed, Feb 10, 2016 at 12:45 AM, darkdragon <darkdragon-001@web.de>
>> wrote:
>>
>>> Currently, you need at least 7(!) characters plus the actual name just to
>>> use one variable. This is quite much to encourage users to use it!
>>>
>>> Why do you need "--" AND "var()"?
>>> Wouldn't be one of it be enough?
>>>
>> We need the -- in var(--foo) so that the name matches exactly between
>> definition and use. Anything else is potentially confusing, and makes
>> searching in a document harder.
>>
>> We need a var() function for a few reasons.  For one, there are a few
>> places in CSS where you can have arbitrary names already, like counter
>> styles or animation names, so allowing a bare custom property name
>> would be ambiguous there.  Theoretically we could make it invalid to
>> name your @keyframes or @counter-style rule something that looks like
>> a custom property name, but that means more rules for authors to
>> learn.
>>
>
> I think it would be good to go ahead and do this. I've used CSS variables
> and find that having to declare each variable reference twice—once with
> var() and again with the "--" prefix—is onerous. Being able to eliminate
> var() would continue to address your first concern (i.e., syntax
> consistency) while making the feature significantly easier to use.
>
> One reason it's onerous aside from the verbosity, is that if I create a
> custom property like --color, then try to copy and paste what I just typed
> to multiple locations, I can't do that without first typing "var(" at the
> beginning of what I pasted and ")" at the end of what I pasted, then
> copying that before continuing the paste process. In case it's not obvious,
> I arrive in this situation because it's typically the case that I'll write
> part of a style sheet before deciding that I need variable to ensure that
> certain parts of the style remain consistent.
>
> For two, var() is required in some circumstances, like when you want
>> to provide a fallback.  In general, a language shouldn't provide
>> multiple ways to do something unless there are good reasons for each,
>> and there isn't a strong reason to omit var() when you're not using
>> any other functionality, so I don't allow it.
>>
>
> The name of this feature, var, provides no indication whatsoever that it
> permits fallback values. This is the first I've heard of that functionality
> and finding it in the spec isn't obvious either because the fallback
> feature's description doesn't have its own section. This seems inconsistent
> with your "readability and understandability" principle (quoted below).
>
> It also seems strange to have this feature, which is unrelated to
> variables, be part of the Variables module when there's already a
> Conditional Rules module that does the same thing. This seems inconsistent
> with your "a language shouldn't provide multiple ways to do something"
> principle.
>
>
>> Why not something like "v()" as a shortcut (people using jQuery and stuff
>>> are used to such shortcuts!)?
>>>
>> While I highly value terseness in CSS and promote it whenever
>> possible, it must be balanced against other concerns, like readability
>> and understandability.  Single-letter names are generally a bad
>> tradeoff here - they only save a little bit, but they make it much
>> more difficult to tell what's being referred to.  The name "var()" is
>> already abbreviated from "variable()", but it's a pretty unambiguous
>> cut, and anyone working in the web platform is already familiar with
>> "var" from JS.
>>
>
> If this was seriously a concern, then the syntax would have been something
> more like -var-property so that custom property declarations are clearly
> variables. But it isn't.
>
> And, if authors can do without a var() equivalent when invoking variables
> in other languages, I think authors can do without it in CSS. "--" is the
> syntax CSS is using for declaring variables and "--" is required when using
> variables; that follows the paradigm of languages like PHP and is more than
> is required in languages like JavaScript, which doesn't use variable
> signifiers at all.
>
> For more perspective, imagine having to type var() or let() around every
> variable use in JavaScript; that would be absurd.
>
>


-- 
Cheers!
Praveen ◉ praveenpuglia.com ◉ @praveenpuglia
<https://twitter.com/praveenpuglia>