W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: Brian Kardell <bkardell@gmail.com>
Date: Thu, 14 Jun 2012 17:16:35 -0400
Message-ID: <CADC=+jeFt8gmW4V5cmtbBptP+tp80Td=NcdnhiLsf2dDauBSNw@mail.gmail.com>
To: François REMY <fremycompany_pub@yahoo.fr>
Cc: Divya Manian <manian@adobe.com>, CSS 3 W3C Group <www-style@w3.org>, Tab Atkins <jackalmage@gmail.com>
Just one note, as Tab pointed out to me yesterday evening and rightly
so:  They are _author_ defined properties, not _user_ defined
properties from the perspective of CSS.

On Thu, Jun 14, 2012 at 5:04 PM, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> | 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:17:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT