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 <ernie@ern.me>
> *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
>

Received on Friday, 10 February 2012 15:18:48 UTC