W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css-variables] using variables in shorthands

From: Shane Stephens <shans@google.com>
Date: Thu, 15 Mar 2012 08:19:59 +1100
Message-ID: <CAGTfzwTPhT1C261-yaSGAo=gqJLctzYYXQpib0eyN6ER1xK0sg@mail.gmail.com>
To: Florian Rivoal <florianr@opera.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
> 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.

Why not make this a function, say 'expand'? For your example above:

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

document.styleSheets[0].cssRules[0].style.backgroundColor = expand(data(foo))

The effect of the function is to expand a shorthand property value to
a longhand property value. I think using this approach means that
backgroundColor operates pretty much the same as width does if I do
something like this:

a {width: calc(100px + 50%);}

document.styleSheets[0].cssRules[0].style.width = calc(100px + 50%);

> 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

So this becomes:
* When shorthands do contain variables, store the variable expression
  in the shorthand, and 'expand(<expression>)'
  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.

Functions that can't be evaluated until compute time are already part
of the specification, so this step reduces to two cases.

> 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

This process becomes analogous to calc resolution, and there's no
explicit dependency on the resolved shorthand 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

This reduces to the existing cases of regular value (including
functions) or value with unexpanded variables.

> * 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.

Interesting. You need to do this regardless of the specified values
problem you brought up. We should add something to the specification
about this. Tab?

Received on Wednesday, 14 March 2012 21:20:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:13 UTC