New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
heycam opened this Issue Jan 31, 2016 · 10 comments

Comments

Projects
None yet
7 participants
@heycam
Contributor

heycam commented Jan 31, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shans

shans Feb 1, 2016

Contributor

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.

Contributor

shans commented Feb 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shans

shans Mar 11, 2016

Contributor

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.

Contributor

shans commented Mar 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Mar 14, 2016

Contributor

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

Contributor

FremyCompany commented Mar 14, 2016

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

@heycam

This comment has been minimized.

Show comment
Hide comment
@heycam

heycam Aug 10, 2016

Contributor

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.

Contributor

heycam commented Aug 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shans

shans Aug 17, 2016

Contributor

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.

Contributor

shans commented Aug 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shans

shans Aug 17, 2016

Contributor

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

Contributor

shans commented Aug 17, 2016

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

@shans shans self-assigned this Aug 17, 2016

@jyc

This comment has been minimized.

Show comment
Hide comment
@jyc

jyc Aug 17, 2016

Contributor

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).

Contributor

jyc commented Aug 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Nov 9, 2017

Member

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/w3c/css-houdini-drafts/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/w3c/css-houdini-drafts/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.
Member

css-meeting-bot commented Nov 9, 2017

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/w3c/css-houdini-drafts/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/w3c/css-houdini-drafts/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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jul 2, 2018

Member

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.

Member

tabatkins commented Jul 2, 2018

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.

@tabatkins tabatkins removed the Needs Edits label Jul 2, 2018

@heycam

This comment has been minimized.

Show comment
Hide comment
@heycam

heycam Jul 2, 2018

Contributor

Thanks, that works for me.

Contributor

heycam commented Jul 2, 2018

Thanks, that works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment