Re: [css-variables] using variables in shorthands

On Tue, 13 Mar 2012 19:05:01 +0100, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Fri, Mar 9, 2012 at 7:35 AM, Florian Rivoal <florianr@opera.com>  
> wrote:
>> Am I missing something? Does anyone have a better solution? I am left  
>> with
>> the impression that the variables proposal has a fundamental
>> incompatibility with shorthands.
>
> You're not missing anything here - this is indeed problematic.  I can
> come up with only three ways to resolve it:
>
> 1. Drop this property-like thing we have going, or at least drop
> inheritance.  Revert to SASS-like variables, possibly returning to the
> @var syntax from my earlier blog posts.  This avoids the whole issue.

> I'm against #1 if we can avoid it.  I like multiple aspects of the
> current solution, and think there's a lot of opportunity for cool
> extensions in the future.  A lot would be lost if we went back to the
> "all vars are global" version.

Definitely. The current proposal is both more powerful and more elegant
than previous proposals, so I'd rather we kept it. If if can be made to
work, that is.


> 2. Since var properties can only refer to other var properties, define
> a separate inheritance step for them.  They "compute" separately from
> (and before) other properties do, so that by the time you look at a
> normal property's specified value to see how to expand it, the
> variable is already fully resolveable.

> #2 seems a little hacky, but there's nothing *theoretically* wrong
> with it.  I have no clue how hard it might be to implement, though.  I
> prefer this option if it's possible, though.  (This does constrain our
> options in the future somewhat.  We can't, for example, use the
> inherited value of an arbitrary normal property as a variable - there
> wouldn't be any circularity concerns, but it would require us to wait
> for the "real" inheritance to happen first, and would thus break our
> invariant unless we get hacky.  I don't think this is a huge deal,
> though.)

I think there is something theoretically wrong with it. Even if you
define a separate variable computing stage, you need an element tree
to be able to resolve anything. Given the following style sheet:

a {background: data(foo);} p { data-foo: blue;} div {data-foo:red;}

you can't resolve the color of an a element until you know if it is
a descendant of a p or of a div. So there is no separate step that tell
you what the value of this should be:

document.styleSheets[0].cssRules[0].style.backgroundColor

> 3. Somehow hack the way we expose computed values to hide the problems
> here.  I have no idea how this would work, because of the fact that
> longhands turn into shorthands over time.

> I have no clue what #3 might entail, so I can't really evaluate it.
> If anyone has any good ideas, I'll listen.

I don't quite know what you mean here.

> Thoughts?

The only thing I can think of is that we should change the way we expose
specified values, so that you can return something that means "currently
undetermined, depends on variables", and change the way things cascade.

Essentially:,

When you parse:
* when shorthands don't contain variables expand shorthands into
   longhands, and store only that
* When shorthands do contain variables, store the variable expression
   in the shorthand, and a special "it depends on the shorthand" value
   in the longhand

When you cascade
1) resolve the computed value of data-properties
2) apply the cascade "normally" to find out the computed value
    of each longhand. They may either resolve to regular value,
    a value that contains a variable, or to a "it depends on the
    shorthand" value.
3) expand variables in all properties (shorthands and longhands)
    that uses them directly
4) for each longhand that had been resolved to "it depends on the
    shorthand" use the now resolved shorthand to compute the value

When you query the DOM:
* When asking for the specified value, you can either get a regular
   value, a value containing unexpanded variables, or a "it depends
   on the shorthand" special value
* When asking for the computed value of longhands, use the result
   of the cascade as described above.
* When asking for the computed value of a shorthand, don't use
   the result of step 3 of the cascade above. Regenerate it
   from the longhands as computed at step 4.

Of course, more devils hide in the details, but I think that this
approach would work. That said, this would pretty much a complete
rework of the way the cascading code works, and I am really not
looking forward to that.

I hope someone can either find something simpler, or propose a
subtle variant of the variable proposal that retains its advantages
without clashing with shorthands.

  - Florian

Received on Wednesday, 14 March 2012 11:01:20 UTC