Re: [css-variables] status ?

On Fri, May 25, 2012 at 7:57 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Sorry, but I am totally lost here. Too much signal. Tab, I know it's yet
> another thing added to your radar but could you please try to gather a
> summary of the recent discussions on variables? I am totally lost about
> the $ notation, what changes you accepted or not, which ones you
> consider or not. BTW, the Editor's draft has no "Changes from last
> version" section ;-)

That's because I haven't made any changes yet.  ^_^

Anyway, yeah, here's a summary of what changes I'd like to make:

1. Basic variable usage is done like "$foo", rather than "var(foo)".
I'd wanted to do this originally, but I presented a function-based
syntax instead in the hope that it would help the draft slide past the
WG's resistance.  Afterwards, I convinced myself that the functional
syntax was actually necessary to accommodate some of the additional
abilities I wanted to add, but Chris Eppstein showed me this wasn't
true.  This appears to be *very* popular with authors - I made a
single oblique tweet about it, and got nearly a dozen very positive
responses, and zero complaints.  (That's quite unusual - there's
usually a few naysayers when I tweet about my proposals. ^_^)  As far
as I know, at least some of the WG also supports this - after my
presentation of the draft at TPAC, a few people pulled me aside and
asked me about using $foo as the syntax.

2. The var() function still exists, and now takes a second optional
argument for fallback.  Basic usage like "var($foo)" is identical to
just "$foo".  If you provide the second argument, it's used instead if
the variable is undefined or invalid.  This allows for easier use of
var() as a templating mechanism, and is a necessary component of a few
more advanced use-cases.  It's also necessary for us to integrate with
SVG's plans for "SVG Parameters" that was presented a few years ago,
where you pass "variables" into an SVG file via url params.

3. Add a parent-var() function.  Syntax is identical to var().  It
returns the *inherited* value of the variable instead of the current
variable.  This is necessary for a few pretty nice use-cases, like the
variant on cycle() that was discussed, or for accumulating a value in
a variable.  It's also the best solution we've come up with so far for
providing styling hooks for Web Components (and possibly for other
things that use shadow DOM, like form inputs and such).

4. Tighten the syntax of variables.  This should be pretty
non-controversial, as the current definition is way to underdefined.
This is easy to do - basically it'll just be a space, comma, or
slash-separated list of "[ <number> | <dimension> | <string> |
<function> ... ]".  Very permissive, but still disallows weird things
like unbalanced parens and such.  The WebKit impl already uses this
slightly restricted grammar (we basically parse it as a "term+", from
the Appendix G grammar).

5. Slightly change the behavior of "invalid at computed-value time"
properties so that they revert to either their initial or inherited
values, depending on whether the property is inherited.  Right now
they always do the initial value, which is somewhat unintuitive.

That's it, other than some minor obvious fixes and cleanups that have
resulted from feedback.

~TJ

Received on Friday, 25 May 2012 16:32:13 UTC