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

Thanks @alice,

**Q: What's the behavior of a custom property that is used in CSS before it is defined in script? (etc)**

I assume you mean the case where a custom property is first declared somewhere, and then some time later a syntax is registered for that custom property, while the pre-registration value still exists.

It's important to note that registering a property does not affect the cascade. This means that a custom property that has its specified value "invalidated" by an after-the-fact registration still has that same "would-be-invalid" specified value after the registration. Only when calculating the computed value is the registered syntax (if any) taken into consideration. This behavior ensures that we don't have to reparse/recascade when registering properties (only recalculate computed values). I thought the spec handled this problem well enough, but apparently we can improve there.

Now, for the parts not handled at all by the spec:

CSS OM:

 * Registering a property does not change CSS OM behavior when getting values from declared `CSSStyleDeclaration` objects. This means that if you first declare `--x: 10px` in a stylesheet, then register `--x` with the syntax `"<color>"` (for example), and then grab the value via `CSSStyleDeclaration`, it will still produce ` 10px` (and not an error or an empty string, for example).
 * Registering a property _does_ change CSSOM behavior when _setting_ values on declared `CSSStyleDeclaration` objects. If `--x` is registered with `"<color>"`, an attempt to set a value that does not match the `"<color>"` syntax will fail. This behavior is not very consistent with "syntax ignored until computed-value-time", and I'm not sure if I like it, but [it's what Tab wanted](https://github.com/w3c/css-houdini-drafts/issues/778#issuecomment-406440820).
 * Registering a property changes the behavior of computed `CSSStyleDeclaration` objects, but that should follow from [2.4 Calculation of Computed Values](https://drafts.css-houdini.org/css-properties-values-api-1/#calculation-of-computed-values).

CSS Typed OM:

 * When grabbing an already-defined value via declared `StylePropertyMaps` after registering, the value is parsed (on its way out of the API) against the syntax, and then [reified](https://www.w3.org/TR/css-typed-om-1/#reify-stylevalue) according to type of the value that was parsed. If that parsing fails, the value is reified as if the custom property is not registered.
 * When setting values post-registration, the incoming `CSSStyleValue` must [match](https://www.w3.org/TR/css-typed-om-1/#match-a-css-production) the registered syntax.
 * When grabbing values from the computed `StylePropertyMapReadOnly`, the value is reified according to the type of the underlying value (which again is determined by the registered syntax).

**Q: How are the syntax classes defined?**

In section 2.3. "Supported syntax strings"? :-)

Maybe I don't understand the question.

**Q: Is it possible to define new classes from script?**

No.

**Q: Why are the syntax classes defined as strings?**

The syntax string itself has internal syntax. E.g. `"<length>+ | <percentage># | auto"` describes a space-separated list of lengths, or a comma-separated list of percentages, or `auto`. This can't easily be represented by e.g. an enum.

Also:

 * We want to be flexible to allow for more complicated syntax in the future. I think there is a secret desire to eventually support the full CSS metasyntax.
 * Whatever solution we have for specifying the syntax must also work for the planned [declarative version of the API](https://github.com/w3c/css-houdini-drafts/issues/137), and should be as similar as possible to the JS API.
 * There is an [open issue](https://github.com/w3c/css-houdini-drafts/issues/112) to describe the grammar of the syntax string. This issue is currently blocking shipping in Chrome.

**Q: Is there a CSS Type'd OM version of this API?**

No. I don't know if it's appropriate for CSS Typed OM to be involved here or not (specifically w.r.t. the syntax definition). [Apparently](https://github.com/w3c/css-houdini-drafts/issues/197#issuecomment-246535942) there has been discussion around this before (using JS objects to define syntax), but the conclusion seems to be that we don't want that.



-- 
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-462277840