Re: [css-variables] CSS Variables are a NEW kind of variable

| No, I do not think they are equivalent! Data attributes are mere vehicles
| of declaring a variable that you would want to manipulate from within your
| application.
|
| "Custom data attributes are intended to store custom data private to the
| page or application, for which there are no more appropriate attributes or
| elements." -
| http://developers.whatwg.org/elements.html#custom-data-attribute

I could make a sentence very close to it depicting how 'css user-defined 
properties' should work, if I would : "Custom CSS properties are intended to 
store custom styling information for the stylesheet or application, for 
which there is no approriate CSS property." This includes shimmed properties 
(like 'my-zoom: 5; my-translate-x: 200px; my-translate-y: -100px') and 
application-wide defined colors (which is a styling information which can't 
be represented otherwhise using existing CSS properties)



| CSS variables are used as values for CSS properties. You can't use a html
| custom data attribute as a value within HTML markup. You cant do
|
| <img src=data-fancychart-url
| data-fancychart-url="http://lolcats.com/bikeshedding-cat.gif">

Actually, the only reason you can't do this is because it doesn't make sense 
in current HTML because you would use it on the same element you defined it 
on meaning you just wasted chars. However, when XBL (or a similar HTML 
Components specification) will be implemented by browser you will be able to 
do this :

    page.html:
    <div data-fancy-chart-url="..." style="behavior: url(myBehavior.xbl)" />

    myBehavior.xbl:
    <component>
        <content>
            ...
            <img import-attributes="src=data-fancy-chart-url" />
            ...
        </content>
    </component>



| This completely renders any further comparisons to each other invalid.

Not anymore.



| I am not sure what you mean by implementation level. At implementation
| level I am pretty sure variables are worked on differently compared to
| other properties. The recent commits on the WebKit nightly builds suggest
| that to be the case http://trac.webkit.org/changeset/120154

Give the relatively small number of changes in this set, I guess this is 
only a minimal CSS OM, a modified version of the tokenizer and the mechanism 
used to replace the variable tokens by their value at computation time 
(which requires to modify multiple files). Also, variables are probably 
stored differently than usual properties because they are not immediately 
converted to values. I guess 95% of the code remained shared with normal css 
properties if you consider cascade & co.




| 1. New term 'variable', 'label', <insert other bikeshedding words> that is
| clearly defined in the CSS spec. This way, if CSS requires certain
| properties to never accept a variable, we can do so in the spec.

Wathever the chosen name, this will be done.



| 2. Easy to understand/use syntax for defining a variable (including a
| default value) and clear articulate functions to either get or set them
| (var-get(), var-set(), <I-am-not-a-language-designer-disclaimer>).

I hope we can reach an agreement on this. I think we all agree current 
syntax (var-, var()) is suboptimal.



| 3. CSSOM representation that defines how variables can be accessed via
| JavaScript.

Can't agree more! If you want my point of view on the matter, we just need 
to tweak to tweak

    + DOMString getPropertyValue(DOMString property);
    + DOMString getPropertyPriority(DOMString property);
    + void setProperty(DOMString property, DOMString value, optional 
DOMString priority);
    + DOMString removeProperty(DOMString property);

to notice say they should thread variables like any other properties. Then 
we're done very quickly and it will work like a charm.

    myElement.style.getPropertyValue("my-preferred-color","lime");
    //or: myElement.style["my-preferred-color"] = "lime";

Received on Thursday, 14 June 2012 21:05:26 UTC