Re: [css-variables] a more "Classical" approach

> > There is a slight misunderstanding here. The [css-variables] specs 
> > defines "Custom Properties". What you propose is a Macro system similar 
> > to what you can have in C/C++. Those are two different things which aim 
> > at solving different use cases (though some use cases can be solved by 
> > both approaches, this isn't a requirement per se).
>
> I don't really thing so. Macros, one may say, are "text subtitution".
>
> what I'm trying to propose is something like "temporary style storage", 
> which when used, is to be "joined" with "current main css", much like 
> tables are joined in RDBMS.

Not sure what you mean, but the current plan are to work on macros; I don't 
see how your example is any different from what a macro provides. Could you 
please detail how you propose is different from a macro in a concrete 
example?


> > FWIW, the “$” char has been used for Custom Properties in the past but 
> > is now reserved for a Macro system like the one you propose; it will be 
> > introduced in the coming years once Custom Properties will have more 
> > implementations.
>
>
> 1. are there any public documents regarding those Macros?

Not sure; they are not a top priority right now but if there's anything yet, 
Tab Atkins must now about it.


> 2. as far as I can tell, having "those Macros" (or the "macros I 
> propose"), would provide a better way to keep "common css features" in one 
> place, then the "--*" / "var()" extention. And additionally, it doesn't 
> give a way to "procedural CSS", which is a "good thing".

The whole mistake was to call them variables. This was misleading because 
those are not variables in the usual "CSS Variables" usage.


> So if there is any other document containig reasoning in favour of 
> "--*'/"var()", I'd apreciate a pointer so I can read it and see the big 
> picture I'm currently missing. With only the reasoning found in 
> http://www.w3.org/TR/css-variables-1/, I'd say, that having it 
> standardised before Macros looks a bit like a waste of time.

- Custom Properties allow developers to add design meta-data to their 
elements which they can read from JavaScript.
- Custom Properties allow developrs to create/polyfill new css properties, 
with the help of a companion script.
- Custom Properties can be overriden at the element level, which allows 
DOM-aware variables:
--> example: you can define "primary-color" as red for your page, but green 
in a specific widget; all components inside the widget will have the usual 
styling but because the "primary-color" custom property will be inherited to 
green, they will render differently inside or outside of the widget.

In addition, Custom Properties references (var(--property-name)) allow to 
solve the usual variables refactoring problem faced in CSS. It is kinda like 
a two-in-one. The only thing variables do not solve but macro would is 
mixins.


>>> The original proposal does allow for "if (x > 5) this.width = 10", which 
>>> I think is simply wrong.
>> This isn't quite true. The idea is that you can write almost anything in 
>> a custom property, including things that does not mean anything in CSS, 
>> like in this case; if you try to use it anywhere, it still isn't valid 
>> CSS. Maybe this confusing example should be removed.
>
> No. I don't thing it does confuse me. I think the example is very valuable 
> as eyes openner.
>  So, If by "custom properties" (CP) as per this document, you try to 
> introduce "alternative javascript", so that a web-author can "do anything 
> with CSS", when the actual problem at hand is noticable excesive 
> redundancy of CSS files as per current standard; then I do think that the 
> proposal is just plain wrong.

This is exactly what I tried to say: you can't use Custom Properties to "do 
JavaScript". Custom Properties do not allow to use javascript or any other 
computing language inside a property value. You can write javascript 
statements or about anything else in a Custom Property, but these are only 
understood as a meaningless list of tokens, they do literally nothing. No 
one sane would ever do this.

Reread the example description: "The allowed syntax for custom properties is 
extremely permissive. For example, the following is a technically valid 
custom property: [[--foo: if(x > 5) this.width = 10;]] ... However this 
value is obviously useless as a variable in css." The idea here is that a 
JavaScript could technically do "eval(myElement.usedStyle['--foo']))" but, 
again, I don't think anybody sane would do this.

This is why I think this example is confusing: if you read it too fast, you 
may think Custom Properties allow conditions and statements, which isn't 
true at all. They just allow to write any almost-arbritary content, because 
CSS does not try to understand it.

Received on Wednesday, 4 June 2014 15:13:48 UTC