- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Jul 2019 08:28:15 +0000
- To: public-houdini-archive@w3.org
> losing the reification behavior sucks. :(
From the author's perspective, yeah :crying_cat_face:. But a `<length>`-registered property being `CSSUnparsedValue` at parse-time/specified-value-"time" is _actually the truth_. Since the parser _is_ producing a typeless token stream, I think it's appropriate that we reify accordingly. We probably shouldn't try to "fix" this problem in the wrong place, instead we should try to change what is true in the parser. (Though this is probably also hard, and there's that resolution that says we can't).
I can't see any good way to solve everything in this case. :(
One related thought is that we could allow any object-value through Typed OM (regardless of registration status), and in general allow custom properties to hold any value (not just token streams).
```
// (Don't know or care if --x is registered or not)
elm.attributeStyleMap.set('--x', CSS.px(10));
elm.attributeStyleMap.get('--x'); // Returns CSSUnitValue
```
In other words, the underlying value created from `CSS.px(10)` retains its type such that we can reify the same type back. If `--x` turns out to be registered with a syntax that doesn't match, it's invalid at computed value time. If it's not registered, it substitutes as the tokenized serialization of the value. Note that this would apply to css-variables, not css-properties-values-api. At least this gives us some minimal typeness for specified styles.
--
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/pull/912#issuecomment-508677646 using your GitHub account
Received on Friday, 5 July 2019 08:28:17 UTC