Re: [css-variables] using variables in shorthands

Forgive me if I'm misunderstanding the problem, but this question
sounds like its similar to what getComputedStyle and "resolved value"
does.

Now, getComputedStyle is a misnomer, because is doesn't always return
the "computed value". It returns "resolved value", a concept
introduced in the CSSOM spec. "Resolved value" is equivalent to
"computed value" in most cases. For a select few properties, "resolved
value" returns the "used value" as long as the "used value" of the
display property is not "none". I assume it has this clause about the
display property because the "used value" relies on resolving layout.

With my naive understanding of the situation, it sounds like calling
.style on a variable rule should behave like getComputedStyle and
return something like "resolved value" . That is to say, if you can
determine "used value" (because "used value" of "display" isn't
"none"), return that. Otherwise, return "computed value".

Just to be clear, "computed value" would look like: "data(foo)" and
"used value" would be "red".

This is similar to what Shane suggests but automatic. If we don't want
that automation, I'd say explicitly use getComputedStyle() rather than
introducing expand().

Mike Sherov
Lead Programmer
SNAP Interactive, Inc.
Ticker: STVI.OB

Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My
thumbs can't create flowery prose.

On Mar 14, 2012, at 6:47 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> 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 Saturday, 17 March 2012 15:45:46 UTC