[css-properties-values-api] When can reifying a registered prop's value ever hit step 7?

[tabatkins]

Currently, step 7 of the computed-value reifying algorithm https://drafts.css-houdini.org/css-properties-values-api/#reify-a-registered-custom-property-value says to reify as a CSSStyleValue, if all the previous steps failed.

This isn't correct as-is (it needs to specify what property it's for), but also, I'm not sure how it could ever hit that case in the first place. Step 6 catches if it's a <declaration-value> already, and since it's the value of a declaration that you're reifying, that seems to catch 100% of cases, right?

So I think instead we should delete step 7, and change step 6 to just be an "otherwise", without a further condition.

[tabatkins]

/cc @andruud

[andruud]

This isn't correct as-is (it needs to specify what property it's for)

You mean we have to set the [[associatedProperty]] to the current property?

Step 6 catches if it's a already, and since it's the value of a declaration that you're reifying, that seems to catch 100% of cases, right?

I tried to express concern about this previously, but probably failed to do it clearly. What I wanted to do here (without quite knowing how), was catch the case where the underlying value is a value without additional type attached to it (and part of my concern previously was whether the idea that underlying values "have a type" is a valid concept in the spec universe---naturally it's a valid concept in Blink). In other words, it should catch values that result from * syntax only. So ... if <declaration-value> catches everything, is there another way to express this?

Since * can't be combined with anything else, I suppose we could just avoid the problem by checking the syntax and always reify a list of component values if it's *. Probably as the first step.

So I think instead we should delete step 7, and change step 6 to just be an "otherwise", without a further condition.

Won't that cause <color> and other things that aren't explicitly mentioned to reify as a list of component values? I think we do need to fall back to direct CSSStyleValue in the general case. Or explicitly mention everything.

[tabatkins]

You mean we have to set the [[associatedProperty]] to the current property?

Currently, yes. That algo requires you to pass a value and a property name.

What I wanted to do here (without quite knowing how), was catch the case where the underlying value is a value without additional type attached to it

I don't quite understand what you mean by this. Can you elaborate?

Won't that cause <color> and other things that aren't explicitly mentioned to reify as a list of component values? I think we do need to fall back to direct CSSStyleValue in the general case. Or explicitly mention everything.

Ah, yes, that's not what we want. Since <color> doesn't yet have a specialized type, it needs to reify as a CSSStyleValue associated with the custom property in question. That is indeed different from a list of component values.

So yeah, then, step 6's condition should be "grammar isn't *", and then should "reify as a CSSStyleValue" for that custom property, then step 7 can handle the rest with a "reify as a list of component values".

[andruud]

What I wanted to do here (without quite knowing how), was catch the case where the underlying value is a value without additional type attached to it

I don't quite understand what you mean by this. Can you elaborate?

Er, I'll try, although it's clearly not going well so far. 😛

Rephrased question:

If I parse a string against * syntax, I get some underlying value. How do I catch that underlying value (in the spec) without also catching values that result from other syntaxes (e.g. parsed against "<color>", "<length>", etc)? Can we do that by looking at the value only (and not the syntax it came from)?