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

[andruud]

I assume @property rules overwrite previous rules with the same name, e.g. if you specify the following, then --x is a <length>, and not a <color>:

@property --x { syntax: "<color>"; inherits: false; initial-value: red; }
@property --x { syntax: "<length>"; inherits: false; initial-value: 10px; }

However, what happens when registerProperty and @property are competing? Currently, registerProperty fails if something is already registered, yet for @property it's probably more natural that it re-registers the property.

Proposal:

• registerProperty fails is the property is already registered, regardless of the origin of that registration.
• @property will re-register the property if the current registration originated from @property, but fails (i.e. has no effect) if the current registration originated from registerProperty.

[emilio]

Copy pasting from #902:

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).

[tabatkins]

Agree. I'm inclined to have script-registered properties win over rule-registered ones.

[tabatkins]

All right, specced that @Property rules for the same name have last-wins semantics, and that registerProperty() wins over @Property rules.