Re: [css-variables] Custom properties using the 'var' prefix? (Issue 1, !important)

> From: Tab Atkins Jr.
> On Thu, Sep 6, 2012 at 2:40 AM, François REMY <fremycompany_pub@yahoo.fr> 
> wrote:
> > Most of us don’t understand why, when ‘Variables properties’ were 
> > renamed
> > into ‘Custom properties’ in the spec, the spec itself wasn’t renamed 
> > ‘CSS
> > Custom Properties’ like our proposal is.
>
> Please don't imply that you speak for the majority of authors.  I
> understand that you feel strongly about the naming issues, but from my
> own unsolicited feedback, lots of people seem perfectly fine with the
> current naming.

Actually, when four people participate actively in the [css-variables] 
discussions and that three of them (Chris, Brian and myself) think something 
against one (you) that thinks the other way, even if we're not 
representative of the majority of authors, we can say that there's a strong 
probability that a majority of authors given the same information as us 
would defend the same position as us.

Also, most people which are 'fine' with the current naming only see that 
'var' and 'variables' make sense. In fact, most of the informed people about 
the spec (and you can't deny this) actually contest the use of the 
'Variables' term in the specification. Take any OO book, you'll have no 
difficulty to see that there are strong differences between variables and 
properties and that it's not possible to be both. Actually, the spec define 
properties and a binding mechanism, which has nothing to do with variables.



> (I was expecting a *lot* more vitriol in my last
> Variables thread, but got virtually none.  Nearly everyone that
> commented on the name said that it made sense to them.)

How many vitriol do you need before considering you may actually be wrong? 
At some point, when the current [css-variables] draft was proposed, this 
mailing list has seen lots of comments whose some where constructive. People 
don't have time to repeat those comments again and again on this list. If 
their point is not understood, at some point, they just leave the 
conversation.

How come that we are so few discussing [css-variables] right now when two 
months ago, with the same draft on the table, most people were crying? Maybe 
my response is directed but I would argue that people are just getting tired 
of giving their point of view. If nothing changed after so many time and 
mails spent on the subject, most of them just expect that nothing will 
change anymore.



> > Also, we contest the ‘var’ prefix being used. If ‘custom properties are 
> > not
> > variables’, using the ‘var’ keyword doesn’t make sense anymore.
> >
> > The name of CSS Custom Properties specification has been chosen on 
> > purpose.
> > Since this spec aims to differentiate itself from macro-like 
> > functionality
> > of preprocessed variables, it doesn't make sense for it to be called CSS
> > Variables. In fact, it doesn't define any variable at all, only 
> > properties
> > and property references.
>
> It's valid to look at it that way, but it's not the *only* way to see
> things.  I think that looking at custom properties as defining a
> variable is a useful mental model.  This is easier to extend in some
> way, too - for example, the SVG Parameters specification can be built
> on top of Cascading Variables just by specifying that a param in the
> URL defines a variable accessible on the root element.

So, has a SVG's URL parameter an higher or lower predecence than the same 
property actually defined on the root element? Seriously, mixing CSS 
properties with URL parameters just don't make sense. Should we also merge 
data attributes and custom properties? That could make an heck of sense... 
or not at all in fact.

Tab, you're certainly confusing two things here. You're confusing 'property 
references' and 'token stream references'. While the use() and inherit() 
proposals are 'property references' and that most of the fallback mechanism 
we defined for them can be shared with other kind of 'token stream 
references', that doesn't force every 'token stream reference' to be defined 
as a 'property reference'.

If our CSS Custom Properties draft is being adopted, we clearly split the 
concept in two, which allow to add very easily something like 'The param() 
functional notation is a token stream reference whose provided value 
corresponds to the value of the URL Parameter whose name is specified by the 
first argument; if such parameter don't exists, the provided value is 
invalid. The fallback value of a param() reference is its second parameters, 
if any'. That, in combination with our draft spec, would be sufficient as we 
abstracted the replacement and fallback logic into a wider concept.



> > This specification uses the 'my' prefix for custom properties on purpose 
> > for
> > custom properties for three main reasons:
> >
> > It's the prefix that developers used naturally, for years, when they 
> > were
> > using or asking custom properties. If necessary, I can find a lot of 
> > samples
> > of that.
>
> I have never seen this.  It would be kind of weird, actually, since
> Perl is the only language I know of that uses "my" in reference to
> variables.

Here we go again. THOSE ARE *NOT* VARIABLES. The WG decided to rename them 
'custom properties' for a reason.



> Mostly, when people talk about custom CSS properties they either use
> x- or don't use any prefix at all.

http://stackoverflow.com/questions/2926326/can-i-access-the-value-of-invalid-custom-css-properties-from-javascript
http://stackoverflow.com/questions/8811027/get-elements-custom-css-properties-mystyle-using-javascript
http://algorizms.blogspot.be/2007/11/custom-css-properties-in-flex.html
http://www.glazman.org/weblog/dotclear/index.php?post/2012/08/17/CSS-Variables%2C-why-we-drop-the-%24foo-notation#c16628
(you can also look at the comment 4, where the author use the 'my' prefix in 
the 'The way I saw variables' part)

I can testify that, in my research, I have globally as many links where no 
prefix is used than I have where the 'my' prefix is used. I also have one 
like where the 'custom' prefix is used. Except the last link which came 
later one, I can testify my research has been done using Google and 
searching for "CSS Custom Properties" so it should not be oriented.

If we remove from my research work every entry where no prefix is used, the 
'my' prefix comes way more often than any other. In fact, I introduced the 
'my' prefix in the spec after the research I did and where it seemed to be 
the most popular one. If you correctly remember, I was proposing the 'x' 
prefix beforehand but Sylvain said he didn't like it, which is why I did all 
this research in first place. If we can agree on the 'x' prefix, I would not 
mind at all.

Received on Friday, 7 September 2012 10:18:52 UTC