Re: [css-houdini-drafts] [css-properties-values-api] Interaction with setProperty is unfortunate. (#880)

At bare minimum, we want TypedOM to do custom-property parsing; it's a good spot to give feedback to the script author that they've made a mistake.

I'd *ideally* have liked to do the whole-world reparse; I don't like the inconsistency either, and it limits the power of registered custom properties in a troublesome way, since now your assumed-under-the-script's-control custom property is beholden to what CSS thinks is valid, but without the protection of fallback. But oh well.

I'd be *willing* to shift on the middle ground of string-OM setProperty(); all I want is some degree of meaningful consistency, so authors can confidently predict when each behavior will occur. So there's a few different places I can see us drawing the error/no-error line:

* "never invalidate from any source": means that explicitly using TypedOM constructed values can't even give feedback to the author, which kinda sucks imo.
* "Typed OM" vs "everything else": This kind of siloing based on specification-origin is awkward; Typed OM does string parses (from `.set()` and `.parse()`), so it's a little more difficult for authors to predict what'll check/throw and what won't.
* "object-based value APIs" vs "string-based APIs": TypedOM's `.set()` and `.parse()` wouldn't throw for bad string values, but passing objects to `.set()` would. Consistent in usage, and so at least somewhat predictable/learnable by authors, but also quite limited.
* "parses caused by HTML" vs "parses caused by JS": stylesheets from `link` and `style` elements, or `style` attributes, don't check validity (whether they were in the static markup or added/modified later via DOM), but any CSSOM operations or other JS things do (including things like Constructable Stylesheets, both forms of CSS.supports(), `el.style["--foo"]` if we end up speccing that, etc.)
* "everything preceding the registration, including all static markup" vs "everything following the registration": any time you parse, invalidate according to the registrations you currently know about, treating all static markup as preceding all registrations to avoid the most common race conditions. (But stylesheets *added by* scripts doing DOM operations are parsed with the currently-known set of registrations.) Anything that gets registered later stays as a valid parse, and invalidates at computed-value time instead. We'd need to tighten up CSSOM to be more specific about when exactly stylesheets re-parse due to OM tickling.

I really don't like the first two. I'm indifferent to the third one. I'd be happier with either of the latter two. Do you have preferences on this, or additional suggestions on where to draw the line?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/880#issuecomment-487711242 using your GitHub account

Received on Monday, 29 April 2019 19:27:10 UTC