- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Jul 2018 06:02:24 +0000
- To: public-houdini-archive@w3.org
Added, 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. 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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/118#issuecomment-401680647 using your GitHub account
Received on Monday, 2 July 2018 06:02:39 UTC