[css-properties-values-api] @property vs setProperty

[andruud]

Given an @property rule in some stylesheet, how should the two-param setProperty()/CSS.supports() behave? They probably need to take into account the registration caused by the @property rule, even if that registration has not yet been effectuated.

Updating "style data" (as @emilio calls it in this comment) during setProperty() seems nasty.

Do we revisit #880? Give up on @property? Accept the nastiness? Something else?

cc @tabatkins

[emilio]

I'd prefer revisiting #880, fwiw.

[tabatkins]

This is why I was surprised to see you announcing @property before talking to me about it. ^_^

We need to nail down the semantics of @property, and how its differing ergonomics from .registerProperty() will play out.

Namely:

1. .registerProperty() can only be called once for a given property name. Further attempts fail with an error.
   1. What happens when you have two @property rules for the same name?
   2. What if you have an @property in a stylesheet, remove it from the stylesheet, then reinsert it? Is the behavior different if the rule is "identical" vs altered before reinsertion?
   3. What if you have an @property in a stylesheet, and then create a new rule for the same property name and use CSSOM to insert it into the sheet before the pre-existing one?
   4. What happens if you edit the text content of a style element containing an @property, which re-parses and creates a fresh stylesheet from its contents?
2. There's no .unregisterProperty() anymore; once a property is registered it exists for the lifetime of the page.
   1. So what happens if you remove the @property rule using CSSOM?
   2. What happens if you remove the stylesheet itself using DOM?

[andruud]

Hehe, I sent an Intent to Implement (behind and flag). It's basically a glorified "Hey guys, FYI, I'm experimenting with this". I wasn't going to go further than that without a sane spec, of course. 😄

I just wanted to get things moving. At least there is some activity on the GitHub side now.

@tabatkins While that list is somewhat intimidating, I'm still more worried about this issue. Because of it, @emilio wants to reopen #880, and basically change the behavior to "never invalidate from any source". I was hoping you would have an opinion on this.

[tabatkins]

Hmmmmmmmm.

I think we need to think over this list to answer the question fully, tho. There are some stacked decisions here that we might be able to more fully unwind if we're revisiting decisions.

To the point: if we give up on invalidation entirely (deferring all of it to computed-value time), then why don't we have the ability to unregister a property? It seems like we'd be free to allow it, then. (I'm pretty sure we chunked that because of invalidation, originally, if I recall correctly.)

And if that's the case, then all the questions up above suddenly answer themselves: the @property rules just cascade normally, with last-in-stylesheet-order winning. Effectively each rule unregisters any previous instance of the name then registers itself.

I am quite interested in seeing @property exist; I'd be willing to give up on TypedOM invalidation if that's what it took to have this all make sense.

[andruud]

To the point: if we give up on invalidation entirely (deferring all of it to computed-value time), then why don't we have the ability to unregister a property? It seems like we'd be free to allow it, then. (I'm pretty sure we chunked that because of invalidation, originally, if I recall correctly.)

Hmm ... unregistering also seems relatively unproblematic with the current state of things (though I may be missing something). Sure, it changes what's accepted by CSSOM/TypedOM, but why is that worse than the transition from not registered to registered in the first place?

I am quite interested in seeing @property exist

Yeah, me too. There's a real chance @property will never happen if this issue remains, that's what's bothering me. I personally care more about @property being a thing, vs. Typed OM invalidation, but that's me.

(The current behavior is enabled in Chrome Beta at the moment, but now I'm leaning towards disabling it before it hits stable).

[emilio]

I agree with pretty much everything y'all have said. Unregistration also doesn't seem extremely problematic.

Giving up on typed om / setProperty invalidation is the easiest and simplest way to make this whole model make sense IMO.

The only other question then is, I'd think, what happens when script-registered and style-registered properties clash. I think the easiest solution to that problem is saying that they're independent (that is, you can't unregisterProperty a property registered via @property, and vice-versa, and then you just need to specify in which order do we look at the two sets if there's a name conflict).

[andruud]

I'm pretty sure we chunked that because of invalidation, originally, if I recall correctly.

For reference, here's the log with that decision: https://logs.csswg.org/irc.w3.org/houdini/2016-09-22/#e727846

Giving up on typed om / setProperty invalidation is the easiest and simplest way to make this whole model make sense IMO.

It seems like it. 😐

The only other question then is, I'd think, what happens when script-registered and style-registered properties clash. I think the easiest solution to that problem is saying that they're independent (that is, you can't unregisterProperty a property registered via @property, and vice-versa, and then you just need to specify in which order do we look at the two sets if there's a name conflict).

That's an interesting proposal! This is #845, BTW.

There is also #846, though that issue is probably not unique to @property.