[css-properties-values-api] Interaction with setProperty is unfortunate.

[emilio]

The reasoning for that is intentional apparently:

#778 (comment)

But I think it's still weird that:

let div = document.createElement("div");
div.style.setProperty("--foo", "bar");

Behaves differently to:

let div = document.createElement("div");
div.setAttribute("style", "--foo: bar");

Is this behavior up-for-discussion? I think it is really unfortunate.

cc @andruud @tabatkins

[emilio]

If setProperty behaves that way, CSS.supports two-value function should probably behave that way. But I still think it'd be much consistent and better over-all if custom properties would only be syntax-checked at computed-value time.

[tabatkins]

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?

(These are roughly in order of increasing invalidation, which by complete coincidence is also the order of my increasing happiness.)

[emilio]

I don't get the "give feedback to the author" point with setProperty. setProperty doesn't throw, so you need to call getProperty afterwards to check if it actually applied, it's not as different as having to call getComputedStyle afterwards, IMO. Also, UAs have console warnings. Firefox can give warnings for invalid property values coming from setProperty to the console, there's no reason Chrome couldn't do the same for registered custom properties.

I think I like 1 and 3 the most of those options, maybe with an special-case for the two-argument CSS.supports function so that you can actually check a string syntax against a custom property?

The fourth one looks pretty hard to define. Does toggling src or such count as a "JS-triggered parse"?

The last one at least is definitely a no-go. Parsing time depends on the network, and if you parse off-main-thread, you can concurrently register a property while you're parsing. Getting some kind of determinism there is really hard.

[tabatkins]

I don't get the "give feedback to the author" point with setProperty. setProperty doesn't throw, so you need to call getProperty afterwards to check if it actually applied, it's not as different as having to call getComputedStyle afterwards, IMO.

Oh, hrm, you're right; my intention (from #778 (comment)) was to make .setProperty() throw for registered properties, like .set() does in TypedOM.

Does toggling src or such count as a "JS-triggered parse"?

4th is one of the easier ones to define, imo, tho I apparently didn't do a good job of describing it. ^_^ The distinction is parses initiated by the host language's semantics, versus CSSOM/etc that interact with CSS concepts directly, independent of the host language.

In definition terms, we'd just be adding text to all the CSSOM methods to do a verifying parse based on current registrations; HTML would invoke the algorithms without that text, and so would get a no-verification parse.

Toggling src is thus "host-language initiated", and would not verify custom properties.

The last one at least is definitely a no-go. Parsing time depends on the network, and if you parse off-main-thread, you can concurrently register a property while you're parsing. Getting some kind of determinism there is really hard.

I'm not sure if you understood what I was saying in 5; all stylesheets parsed from the static markup will be no-verification, so there's no race condition.

The only way to race things is to intentionally kick off a load in JS and then do nothing to sync with it; given how trivial fetch() promises are to work with, I'd be okay with letting authors shoot themselves in the foot there.

Hm, I suppose toggling a src from JS will trigger a more-difficult-to-observe timing of the actual parse, tho.

[andruud]

I had my doubts about this at first too (hence #778), but if we change div.style.setProperty("--foo", "bar") to never validate, it will be inconsistent with how setProperty works for regular properties. We create an inconsistency somewhere either way.

For Typed OM, the spec for .parse() and .set() currently automatically works for registered custom properties, because they behave consistently with standard properties. If we do something like (3), we would need to handle registered custom props as a special case (e.g. if .parse() doesn't throw for invalid grammar, it needs to return something. A CSSUnparsedValue, probably, which seems kind of lame if the property in question is registered as e.g. a <length>). (CSS Untyped OM Level 1)? :P

I do like that the current approach (4, I suppose) does seem to work quite consistently with CSS Typed OM by default. I also think it's appropriate to give consistency with TypedOM extra weight in this matter, since gaining a type (with all that it entails) is the main point of css-properties-values-api. (Though I'm not sure if (4) really is the least inconsistent approach, or if I just got used to how it works, accepted it, and moved on).

[tabatkins]

I do like that the current approach (4, I suppose)

Current approach is 4 if we go back and change CSS.supports() to also return registration-aware values when you ask about a custom property. I'd have to check if there's any other APIs that would be needed to bring into the fold to make it consistent.

I like this one because I think authors can actually learn what the dividing line is, and extrapolate to new APIs.

[foolip]

@tabatkins can you add the css-properties-values-api-1 label to this and #879?

[andruud]

@tabatkins @emilio So, I now have approval to ship this feature in Blink, but I don't think that's wise until we have some minimal consensus here.

I'm feeling a little uneasy about (4), especially re. constructible stylesheets. Not sure how I feel about there being two general parser "modes", where one respects registered syntax and one doesn't.

How about option (6):

• "Validate whenever the JS API interacts with a value directly". This means that two-param CSS.supports gets validation (which @emilio already suggested), but the other form doesn't (it's parsing a <declaration> / <supports-condition> -> not a value directly). CSSStyleSheet.replace (etc) also won't get validation. I may be damaged, but I find this less surprising than the alternative.

[emilio]

I think I find it less surprising too.

[tabatkins]

Okay, so that's kinda a 3.5. To make that a consistent line thru the APIs, it would mean that:

• .setProperty() throws on invalid syntax for registered props
• .supports(prop, val) validates registered props
• all the TypedOM methods throw on invalid syntax

If this is what we settle on I won't be too unhappy, but I don't like it either - it feels very much like a dividing line drawn by internal browser APIs (am I invoking a declaration-value parsing function, or a more general CSS parser?) rather than author-exposed usage patterns (what I was trying to do with 4). But like I said, I'm fine with it if y'all are happy, it's still an improvement over the current world.

[andruud]

@emilio Can you live with this (6 aka 3.5)? (Live with it, not necessarily love it).

(Or do you want to iterate to 3.25, 3.125, etc until we converge on 3? ;P )

[emilio]

.setProperty() throws on invalid syntax for registered props

I think making setProperty throw only for registered props is confusing, I don't think that extra deviation is useful, and I think it should just do what the rest of properties do when you set an invalid value, which is just not setting the property at all.

I think the rest I could live with :)

[andruud]

I think making setProperty throw only for registered props is confusing, I don't think that extra deviation is useful, and I think it should just do what the rest of properties do when you set an invalid value, which is just not setting the property at all.

I was thinking exactly the same thing yesterday, but I was saving this surprise!-opinion for a PR which didn't change the current behavior. ;-)

I think the rest I could live with :)

🎉

[tabatkins]

Yeah, I suppose that's fine. In that case, the only thing that needs changing is:

1. CSS.supports(prop, val) needs to check its value against the currently-registered properties and give a correct answer accordingly.
2. Properties & Values should probably have a note explaining the intention behind this decision, and placing a requirement on future spec authors to conform to this. ^_^