Re: [css-variables] using variables in shorthands

On Wed, Mar 14, 2012 at 4:00 AM, Florian Rivoal <florianr@opera.com> wrote:
> On Tue, 13 Mar 2012 19:05:01 +0100, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> 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

I'm confused.  You need to construct the element-tree before you can
do any assigning of properties (because it's necessary for Selectors
to work in the first place).  Even when it's not necessary (like if
the properties are applied via @style) it's always possible to
construct the element-tree before assigning properties, and you must
do so before you can construct the "cascaded value", which precedes
the specified value stage!

In other words, if I added a rule to the stylesheet like "p a {
data-foo: green; }", I need an element-tree to even see if the rule
applies to the element, let alone whether it wins in the cascade and
inherits.


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

Sorry, I meant "specified value" there.  Your suggestion below falls
into this category.


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

With something like what Shane suggests (expanding the shorthand to
"expand(<var expression>)" in each longhand), this idea does the job
without a significant reworking required.  You still get an
unambiguous specified value for each longhand, *and* properties that
turn into shorthands later have a stable behavior!

+1

~TJ

Received on Wednesday, 14 March 2012 22:46:35 UTC