Re: [w3ctag/design-reviews] CSS Properties and Values API Level 1 (#318)

> @andruud we are just circling back to this on today's TAG call. You noted in your comment above that you were going to draft something. Did that happen? Could you drop a link to that here?

@torgo I have not yet done this. But that would anyway be a separate spec.

> We're trying to figure out to what extent this review should include the unmerged PR at w3c/css-houdini-drafts#847

Hmmm, what I proposed in that PR may or may not be similar to what we end up merging. :-) If you prefer I can request a separate TAG review for `@property` when the time comes.

> w3c/css-houdini-drafts#902

> update on the implementation/shipping status 

Yes, the feature was enabled and about to ship in Chrome, but I disabled it again because of w3c/css-houdini-drafts#902.

The issue is that the spec currently requires some _non-computed style_ APIs to be aware of property registrations. Specifically, 1) [reification behavior for specified styles](https://drafts.css-houdini.org/css-properties-values-api-1/#css-style-value-reification), 2) [setProperty behavior](https://drafts.css-houdini.org/css-properties-values-api-1/#css-style-declaration-behavior), and 3) The two-param form of `CSS.supports` (described in css-conditional, I believe, but that spec seems to down right now).

This is not a problem for `CSS.registerProperty`, as the registration is effectuated immediately when the JS call takes place. However, for `@property` (https://github.com/w3c/css-houdini-drafts/pull/847), the rules cascade and whatnot, and do not take effect until "style data is updated" (as @emilio calls it). This means that calls like `setProperty` would need to synchronously update that style data to know the current set of registered properties, and having to do that synchronously is new and undesirable behavior. The `setProperty` case is also especially bad, since it immediately invalidates the same data you synchronously "flushed".

Hence, we want to specify that APIs don't depend on the registrations (w3c/css-houdini-drafts/pull/912), except for APIs which retrieve the computed style (as these already compute the style synchronously). This would make everything very consistent technically, and accurately represents the actual parse-time behavior of registered custom properties, but it makes Typed OM less useful for specified style, since registered custom properties would be treated as unregistered. The registered syntax of a property would be an aspect of computed-value time _only_, and hence that information is unavailable in other circumstances.

But @tabatkins doesn't like this, therefore this is going nowhere at the moment. Ideally we would have both nice Typed OM/API behavior _and_ a technically consistent model, but I don't see a way to do that.

Anyway, that's the shipping status. 😿 

-- 
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/318#issuecomment-513403693