Re: [css-houdini-drafts] [css-properties-values-api] When can reifying a registered prop's value ever hit step 7? (#897)

> 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 <declaration-value> 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](https://github.com/w3c/css-houdini-drafts/pull/873#issuecomment-479913171), 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.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/897#issuecomment-497857244 using your GitHub account

Received on Friday, 31 May 2019 20:55:44 UTC