[css-properties-values-api] Add @property.

[andruud]

This adds basic support for @property, without solving any of the potentially complicated issues, like #845 and #846.

Resolves #137, at least partially.

[heycam]

@tabatkins @astearns @therealglazou could one of you review and merge this PR if it looks good? Since @andruud is beginning implementation it would be preferable to have this in the spec, so that others can look at it...

[astearns]

I took a look, but @tabatkins should review.

[emilio]

What happens when you dynamically remove an @property rule? What about multiple @property rules with the same name?

[andruud]

Thank you @heycam, @astearns & @emilio.

What happens when you dynamically remove an @property rule?

Then I'd say the property isn't registered anymore. There is a note saying we might add a way to unregister a property ... I guess this does that.

What about multiple @property rules with the same name?

Yeah, this is interesting (since CSS.registerProperty throws if you try to re-register). I assume we want the last one to apply for @property, even if that's the opposite behavior of CSS.registerProperty). WDYT?

[emilio]

Seems ok, though kind of unfortunate... In general having two ways of doing the same is not great IMHO. But "last wins" seems consistent with @keyframes so it seems fair.

[emilio]

Also, I'd note that with the decision we took in #880, it means that setProperty and CSS.supports may need to update style data (I think the Blink concept is doing an active style update?).

I think that's terrible, fwiw, and if I'd have known there were plans to introduce a declarative way of defining these I'd have objected even more strongly to that.

[andruud]

@emilio Please excuse my ignorance, but why would setProperty/CSS.supports need to update style data? (And what is "style data" anyway?)

[andruud]

@emilio Oh, never mind, I see what you mean ... hmm ...

[emilio]

Yeah, sorry, style data is a Servo-ism, it means the "processed" data out of the parsed stylesheets. This is why I used the "active style" concept which is a WebKit-ism :)

But yeah, it basically means that you need to look at whether the processed data from stylesheets is dirty and update it from a setProperty call (since there may be new @property rules for example that you still haven't processed), which I think is really bad, not only for the unexpected, potentially big amount of work that that requires, but also because setProperty at least is a way to potentially dirty this data. Of course you can try to be smarter about invalidating and updating it, but I think it's not great even with that.

[lahmatiy]

* is wrong syntax, since means zero or more occurrences multiplier with missed term before it. Looks like it should be Nothing like for other descriptors if it's a required property, or "<declaration-value>" if it will become optional.

[andruud]

It's not *, it's "*".

[lahmatiy]

Yeah, I mean wrong syntax for a custom property value (inside quotes used specific grammar). So, * is not valid for that

[andruud]

This accepts a <string>, hence "*" is valid in that sense.

What is or isn't a valid syntax descriptor is determined by 3.4.2. Consume a syntax descriptor, not css3-values (directly).

In other words, a single * alone is a special snowflake.

[lahmatiy]

I see, thank you for clarification!

[andruud]

@tabatkins Ouch, my forwards compat! 😱

[tabatkins]

Oh, I misread what you'd wrote there!