Re: [w3ctag/design-reviews] TAG review for CSS Typed OM (#223)

We're starting to review at the London F2F; some stream-of-consciousness questions:

 * Is `CSSStyleValue` really meant to be available in all `Worker` types? E.g., does it make sense in Service Workers?
 * Glad to see constructors on the concrete types!
 * Loving the static methods for shorthands (e.g. `CSS.px()`).
 * Don't understand how [Example 7](https://drafts.css-houdini.org/css-typed-om-1/#positionvalue-objects) works: it looks like the example should work with `styleMap`, but instead it uses `attributeStyleMap`, which doesn't seem like it should have values for `'object-position'`
 * Should [`computedStyleMap()`](https://drafts.css-houdini.org/css-typed-om-1/#dom-element-computedstylemap) be synchronous? It seems to flush style on read...is that right? And does it need to be a function?
 * ...that gets us to a perhaps bigger question: should the OM be trying to help ensure performant read-back and separation of writes/reads? If this is a chance to go that way, it won't come around again. Has it been discussed?
 * to @annevk's point, it looks like [`CSSNumericArray`](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericarray) is a duck-type now. :shrug:
 * @plinss points out that [`[[tokens]]`](https://drafts.css-houdini.org/css-typed-om-1/#dom-cssunparsedvalue-tokens-slot) is a list of strings and not a list of actual tokens. Another way to look at this is that the tokenizer isn't exposed. Should it be?
 * Are changes to [`CSSVariableReferenceValues`](https://drafts.css-houdini.org/css-typed-om-1/#cssvariablereferencevalue) observable without polling?
 * Are there concrete performance numbers we can point to that show the benefits of the Typed OM approach?

Thanks!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/223#issuecomment-362588223