Re: [css-variables] Proposed implementation needlessly complex

Currently, when a variable is undefined, the data() function returns “INVALID”, a special token which is never valid as a property value. The property then reverts back to its “initial” state. It may be desirable to extend the data() function to take a “default” value in the case the variable don’t exist.

    <main.css>
    .darkBg { background: data(dark-background, black); color: white; }

    <green-theme.css>
    html { data-dark-background: #001100 url(‘green-bg.jpg’) top left no-repeat; }

    <red-theme.css>
    html { data-dark-background: #110000 url(‘red-bg.jpg’) top left no-repeat; }

If, for some reason, green-theme.css load very slowly (or fails to load), the default value would be used and text would still be readable (by default, background is transparent which may lead to white text on white background). 

Another solution would be :

    <main.css>
    html { data-dark-background: black; }
    .darkBg { background: data(dark-background); color: white; }

    <green-theme.css>
    html { data-dark-background: #001100 url(‘green-bg.jpg’) top left no-repeat; }
    
    <red-theme.css>
    html { data-dark-background: #110000 url(‘red-bg.jpg’) top left no-repeat; }

Variables will, however, need to be coupled with @supports since we’ll need things like

    @supports(background: linear-gradient(...)) {
        html { data-separator-bg: linear-gradient(...); }
    } else {
        html { data-separator-bg: white url(...) bottom; }
    }

    h1 { background: data(separator-bg); }

François


From: Ernie Bello 
Sent: Friday, February 10, 2012 4:17 PM
To: François REMY 
Cc: www-style@w3.org 
Subject: Re: [css-variables] Proposed implementation needlessly complex
(1) For compatibility, declaring variables outside of any selectors (as is possible with Sass) will indeed break existing CSS docs. Using :root to contain global variables as proposed will work for backwards compatibility and is a good idea. 

I don't think we should be afraid to introduce new concepts or syntax to the language if they make sense and saves the developer time. Using $ to define and return variables is easy to learn and gets around the need to use a function to return values.

(2) Sass variables work the same way, they only exist in the context and selectors you've defined them in. So, I agree, this aspect of the proposal is good. I just disagree with the syntax.

Could you elaborate on potentially creating inconsistencies with default values? I'm not sure what you mean.


On Fri, Feb 10, 2012 at 5:34 AM, François REMY <fremycompany_pub@yahoo.fr> wrote:

  That version of CSS variables has some major advantages, including :

  (1) It doesn’t introduce any new concept to the language, it doesn’t change the language syntax, it has no compat issue.

  (2) The value of a variable can depend on the location in the document. This is really useful since you may want to define variables like “background-color”, “normal-text-color” and “highlight-text-color”. Those will depend on the location in the document.

  Personnally, I was promoting the $var proposal until I saw that implementation of CSS Variables. Seriously, this is the most elegant proposal I had to see yet. But I accept that not everybody share my own personal tastes. And I agree that data(name) is long: I would prefer $name, too, but I think it’s countrary to the CSS conventions and, more importantly, could create inconsistency if we expand variables to more complex cases like default values.

  Regards,
  François


  From: Ernie Bello 
  Sent: Thursday, February 09, 2012 4:42 PM
  To: www-style@w3.org 
  Subject: [css-variables] Proposed implementation needlessly complex
  Web developers have long taken advantage of CSS metalanguages like Sass or LESS to make the benefits of variables a reality before this spec was introduced. The problem I see with the spec as currently written is that the W3C's implementation differs quite a bit from the accepted conventions of these metalanguages.

  Variables should be easy: define a symbolic name for what you need and set it to a value. In order to retrieve the value, use the variable's symbolic name. To use Sass's implementation as an example:  
  $link-color: blue;
  a { color: $link-color; }

  LESS's implementation differs only in the initial character used to define a variable, it uses the @ symbol instead of the $. In contrast, the W3C's proposed implementation is needlessly complex. The W3C equivalent to the above example:
  :root { data-link-color: blue; }
  a { color: data(link-color); }

  According to the W3C, defining a variable is accomplished by data-* properties[1]. That convention seems to have been proposed only due to the "similarity to the custom data attributes" in HTML5. The issue here is a matter of semantics. Data attributes in HTML do not define variables, but properties of an element, and more than one data attribute of the same name can and usually does exist in a HTML document. Using the same notation to define a variable name that shouldn't change doesn't make sense.

  Also, the use of the data function in order to output the property's value is confusing and results in more complex and less readable code. The return output of a function isn't a "variable" in the common sense of the term.

  I believe that the proposed CSS Variables spec should embrace the prior implementation lead provided by Sass or LESS. It will result in a clearer spec and acknowledge the practices already in use by web developers everywhere.


  [1] http://dev.w3.org/csswg/css-variables/#data-property