David: I have reviewed some of this (about half the spec). It's a pretty big spec--attempt to replace CSSOM with something we like better. Some other Mozilla folks have also reviewed due to vendor opinion requests... A couple of issues seemed to rise to the top:

1. Reason was for better performance/ergo for CSS manipulation than working with strings. Wins on ergonomics, but not winning on perf by the evidence.
2. Spec is not yet solid-enough to lead to two interoperable implementations.
3. Few other things maybe not worth discussing.

Alex: we left a lot of feedback from our last F2F... Have recieved some responses already. HAve you processed these?

David: Some were design issues... 23-30 issues + Anne/Boris a similar amount. Spec has had huge changes since the F2F--probably Tab's full-time effort.

Issue: Lots of undefined--what's the underlying model, how is it defined. Spec defines the object model API, but not the model that is being defined. Doesn't say what happens to the model when you change things.

Alex: To a certain extend, browsers don't open up their CSS...

David: More like... complex properties (like transform) have parts, what's the model for how the underlying model for the transform is manipulated, and how the string version is affected, etc.

Alex: We've seen that ambiguity in other parts of the DOM (Attributes/properties). Interop testing has ironed this out... Perhaps implementations have to figure out how that works themselves?

David: Some needs to be fixed in Typed OM, others may need to be distributed to other specs where applicable. Probably other parts need to be defined in CSSOM where serialization is defiend. There's an existing mess, we dont' want to add to the mess without making it better.

Alex: I'm concerned about holding this up for some undetermined long time. I'm also concerned about the lack of definition of a model.

Travis: We should be sure there is clear application of a model.

David: If Chrome implements out ahead, we could get stuck with Chrome's interpretation of

Hadley: Perhaps "OM" is not reflecting the nature of the spec very well... add "API" suffix?

Alex: Worried that Anne's concern is theoretical...

Peter: looks like there are actual side-effects.

Alex: Think we should get to resolutions by writing tests.

Peter: any given property needs to have definition of how they are represented in the object model... we do not want to hold up the rest of this spec until that happens.

Alex: Do we need to channel this feedback to the CSS WG?

Peter: there was a question about needing Proxies to effect this (as it may be slow).

Alex: Chrome doesn't use a proxy.

Peter: Houdini meeting coming up. We can relay the feedback about seeing a consistent OM defined for what parts get set when properties (parts of properties) are changed. David?

David: Nothing else I want to raise here; brought some other issues up to the CSS WG as a whole. Should I write-up the feedback?

Peter: I can do it.

(Note that https://github.com/w3c/css-houdini-drafts/issues/718 may also cover some of this.)