[css-properties-and-values-api] define how typed custom properties influence @supports

[heycam]

We should define how registered custom properties affect @supports. For example if registered with type <length> then @supports (--something: red) would evaluate to false and @supports (--something: 2px) true.

[shans]

I'm leaning towards @supports behaving as in variables-1. @supports is supposed to be used for browser feature detection and it seems like a violation of this idea to allow JS library behavior to modify the result.

Added an issue to the spec so we can track and discuss.

[shans]

Tab has a counterpoint:

div {
--foo: 3em;
--foo: 5newlengthunits;
}

If --foo is registered as a length, then the second declaration will be discarded. @supports should behave the same.

[FremyCompany]

I agree, (a)supports should respect defined value types.

[heycam]

One thing to be mindful of is that this would be the first @supports expression that depends on state inside the document, and which needs to be dynamically evaluated. If custom property registrations change, the @supports rules need to be re-evaluated.

[shans]

Let's add a feature to @supports that allows us to test if a value is a member of a particular type. Then variables can always behave the same (regardless of what they're registered as) and you can use this new feature to solve Tab's problem.

[shans]

Let's just put a note in properties & values and define the behavior in @supports.

[jyc]

Would this be a little unintuitive? We would have "(property: value) implies that property: value is a valid declaration" for all standard properties, but (--custom-property: value) would mean something different (e.g. @supports (--custom-property: invalid-value) { --custom-property: invalid-value } would act strangely).

[css-meeting-bot]

The Working Group just discussed define how typed custom properties influence @support, and agreed to the following resolutions:

• RESOLVED: custom properties are useless in @supports and return true. But separately pursue another predicate that allows you test if a value matches a type where the types are drawn from the set of things custom properties can do.

The full IRC log of that discussion

<nainar> Topic: define how typed custom properties influence @support
<TabAtkins> GitHub: https://github.com//issues/118
<nainar> TabAtkins: When you register a custom property with graammr - infrunece use in @supports?
<nainar> TabAtkins: Or go with current variable behaviour? And always supported?
<nainar> TabAtkins: Latter is closer t oour agreemnt. Parsing wise allow everything. And invliadate at computed value time.
<nainar> TabAtkins: Makes it annoying for when you are trying to do Shane's example.
<TabAtkins> div {
<TabAtkins> --foo: 3em;
<TabAtkins> --foo: 5newlengthunits;
<TabAtkins> }
<nainar> Shane's example^
<nainar> dholbert: authors could hack around this by using width instead of --foo?
<nainar> TabAtkins: yes, hacky. so dont force on authors?
<nainar> dbaron: Does regitering a new custom property force a new parse of stylesheet?
<nainar> TabAtkins: I think no?
<nainar> iank_: Is the example valid? Thought it would take the last one?
<nainar> dholbert: That is for CSSS variables not for ...
<nainar> iank_: resolved that we were supposed to store everything. To avoid reparse?
<nainar> isssue 63 was directly related
<nainar> iank_: Thought we had the ability to take only the last one?
<nainar> astearns: I'm not seeing anythign relavant in current draft
<nainar> dbaron: is ther stuff that wold conceptually force you to reparse the stylesheet?
<dholbert> "issue 63" mentioned above is https://github.com//issues/63 (I hope that doesn't trigger the bot to put notes there)
<TabAtkins> https://lists.w3.org/Archives/Public/public-houdini/2016Feb/0004.html
<nainar> astearns: Still need spec txt to explain this better?
<nainar> TabAtkins: We do reparse custom properties. if you declare foo to be color we throw away any decalation that isnt a color.
<TabAtkins> But if you use "color: var(--foo)", it's valid regardless of registered type for --foo
<nainar> dbaron: but you are only reparsing variable declationr?
<nainar> TabAtkins: Yes not usage. As we didnt want to hold cascade.
<nainar> dbaron: Hesitant as dont want to add ways that registering properties changes more of the stylesheet. E.g you ave stylesheets and script loads happen.
<nainar> dbaron: this means yu now need to block stylesheet load on script load.
<nainar> dbaron: Before you did it the oteer way round.
<nainar> iank_: We only ever look at the second one. If it is invalid we return to initial value
<dbaron> s/did it the oteer way round/only needed to block script execution on style sheet loads/
<nainar> TabAtkins: We only keep the last one.
<nainar> <looks like Chrome breaks fro spec here.>
<nainar> s/Chrome/Blink
<iank_> https://gist.github.com/bfgeek/6e915f873eb30ed5e4e20e14a73cd5cb
<nainar> fremy: there was a proposal to allow decalrion to be in stylesheet. If you do that you dont have to declare this in script?
<nainar> TabAtkins: no you can always manipulate CSSOM ....
<TabAtkins> If you say that @custom-prop can influence @supports, but registerProperty() can't, and peopl ecan just use script to createe a @custom-prop rule, you haven't gained anything.
<nainar> xidorn: you can stop CSSOM fro chaingin ssomething.
<nainar> xidorn: can you change namespace?
<nainar> xidorn: we dont have charset rule in CSSOM for eg
<nainar> TabAtkins: you can ccreate a script element in script and can insert it to doc
<nainar> xidorn: if custom property @rule exisyts it only registers for that one property. Doesnt trigger repasrse of style but affects @supports
<iank_> I've updated the gist to console.log the answers.
<nainar> TabAtkins: We add something to add a type and value and allows us to return ifvalue is supprted by type
<nainar> TabAtkins: if the type is exposed as the same thing as Typed OM uses.
<nainar> TabAtkins: Proposal is custom properties are uselss in @supports and return true. But separately pursue another predicate that allows you test if a vaue matches a type
<dbaron> TabAtkins: ... where the types are drawn from the set of things custom properties can do.
<nainar> TabAtkins: That way you need to know if new value is for eg a length type. but no reparsing is required.
<nainar> TabAtkins: Address dbaron concern . Less hacky that finding . property that parses similarly.
<TabAtkins> @supports type(<length>, 5px) { ... }
<nainar> dholbert: Syntax to be dfined right?
<nainar> TabAtkins: In some wrapper looks like <text above>
<nainar> RESOLVED: custom properties are useless in @supports and return true. But separately pursue another predicate that allows you test if a value matches a type where the types are drawn from the set of things custom properties can do.

[tabatkins]

eAdded, with an explanatory note. This is actually consistent with our parsing behavior; registered custom properties still accept all valid token streams at parse time, same as unregistered ones, but if you violate the registered grammar it automatically becomes invalid at computed-value time. Since @supports tests parsing behavior, it thus should accept anything for a registered custom property regardless of registered grammar.

Note that:

Tab has a counterpoint:

My counterpoint was wrong. In that example, the declaration using a bad unit is still the one that'll get chosen at parse time, discarding the previous one. It'll just then become invalid at computed-value time, resetting to its registered initial value.

Plus, as argued elsewhere, the use-case for @supports with a registered custom property is essentially nil. We need @supports because you're sending stylesheets to a panoply of browser versions, and you don't know what set of features will be valid on any individual one. But with registered custom properties, you know what the feature set is; it's whatever is supported by the library you're currently using. This doesn't change across browser versions; it's completely under the author's control.

[heycam]

Thanks, that works for me.