Re: [css-variables] feedback

On Sat, Mar 29, 2014 at 3:11 PM, Reg Charney <reg.charney@entrebahn.com> wrote:
> It may be too late to comment on this proposal, but I believe that the
> syntax for the proposal is more complicated than needed. Below, I propose a
> simpler and more consistent approach.
>
> 1) The current proposal is confusing because of the "name change"
> requirement. The following simple example shows:
>
>     :root { var-h1color: #06c; var-h2color: #006; }
>     h1 { color: var(h1color); }
>     h2 { color: var(h2color); }
>
> 1a) Why is there a necessity to change a name from its declaration to its
> use?

Check out the latest draft on <http://dev.w3.org/csswg/css-variables/>
- the syntax has changed, so now your example is:

:root { --h1color: #06c; --h2color: #006; }
h1 { color: var(--h1color); }
h2 { color: var(--h2color); }

So there's no longer a name change.

> 1b) Why refer to :root? Is it a "magic" pseudo-class/element or does this
> imply the variables have global scope?

:root just matches the root element.  You could equally specify "html"
in HTML.  It just declares that variable for the whole document by
default, since it'll inherit down to all elements.

> 2) An alternative syntax using the proposed :var pseudo variable eliminates
> both issues 1a and 1b
>
>     :var { h1color: #06c; h2color: #006; }
>     h1 { color: h1color; }
>     h2 { color: h2color; }
>
> I believe that this new syntax makes things simpler and clearer in all
> respects.

I'm not sure what this is trying to do.  I suspect it's attempting to
define global variables?

> 3) Evaluating a variable using the var() function is also unnecessary. The
> default value can be defined using the declaration notation. In the example
> below, if h1Color is not defined, then the default value "blue" is used:
>
>     h1 { color: h1Color | blue; }
>
> Note that this is consistent with allowing expressions in value fields.

That syntax is almost certainly ambiguous, unfortunately, as there's
no way to tell when then fallback value ends.  It looks fine in a
trivial case like the 'color' property, but not in anything more
complex.

Plus, we're trying to limit the use of new ASCII characters in CSS.
We've only got a few left, and authors tell us they find them
confusing, and prefer things with actual names, like functions.

> 4) Any time a property does not conform to the standard list of properties
> for a CSS element, the unknown name is looked up in the stack of variable
> names. If found, the value is substituted; else the value is treated as null
> and processing continues as it does now, including ignoring the issue or
> reporting an error..

I'm not sure what this means.  Can you explain further?

> 5) It is not clear from the current proposal if CSS variables have scope. I
> suggest they can have scope using the :var pseudo class/element. Thus,
>
>     #foo:var { h1color: #06c; h2color: #006; }
>     h1 { color: h1color | blue; }
>     h2 { color: h2color | red; }
>
> defines the variables h1color and h2color only in the range defined by the
> element with id=foo. If the elements h1 and h2 are used outside the range of
> #foo, then the default values, blue and red respectively, are used.
>
> If no scope is defined, the scope is assumed to be global. So, in point 2),
> the variables h1Color and h2Color are global in scope.

Custom properties are just ordinary properties; they apply to
elements, inherit down to children, etc.  The var() function then
takes the value of the custom property on the same element.

So scoping is already built in, piggybacking on existing CSS mechanics.

~TJ

Received on Thursday, 24 April 2014 19:46:31 UTC