-
Notifications
You must be signed in to change notification settings - Fork 142
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
initial value for universal ("*") syntax definition should not allow CSS-wide keywords #1076
Comments
Also see crbug.com/1344170. |
If we remove Since the fallback of a variable ( @property {
syntax: "<length>|<guaranteed-invalid>";
intitial-value: initial;
inherits: true;
} |
WebKit implements this behavior (in https://bugs.webkit.org/show_bug.cgi?id=249305) as it seems obviously correct. I did change the associated WPT (in web-platform-tests/wpt#37941) to allow |
Sorry, but I am missing how CSS-wide keywords are treated specially...
... but it seems obvious that they do not make sense for an initial value, as opposed to a declared value. However I am not sure I understand why they are invalid when the syntax is not
I do not see this case in the WPT, but Chrome also throws a edit: I remembered w3c/csswg-drafts#9078, which mentions the validity of an empty string (or whitespace characters). But here too, edit: sorry, I mixed things up here, and I do not see any use case for using a non-universal syntax with empty string as the initial value, and I am curious what use cases require Unrelated but I also wonder why the rule is invalid instead of just the declaration, although I assume (cf. #1112) that the last valid declaration wins over the previous ones, eg.: @property --custom {
syntax: '<color>';
initial-value: green;
initial-value: initial; /* valid initial-value that invalidates @property */
inherits: false;
} edit: never mind, checking |
Computationally dependent values are now searched in function and simple block values. As per WPT, <*-percentage> is now considered computationally independent, and CSS-wide keywords are invalid with the universal syntax (w3c/css-houdini-drafts#1076), which was already implemented for @Property but not CSS.registerProperty(). WPT also expects var()-containing value to be invalid with the universal syntax, but the reason is unclear so it is not implemented. It is not clear whether keywords that resolve to an absolute value based on another property in a specific context, like smaller in font-size, should be considered as computationally dependent. Current version of Chrome and FF do not, so they are no longer invalid with a non-universal syntax, for now.
Computationally dependent values are now searched in function and simple block values. It is not clear whether keywords that resolve to an absolute value based on another property, in a specific context, like smaller in font-size, should be considered as computationally dependent. Current version of Chrome and FF do not, so they are no longer invalid with a non-universal syntax, for now. As per WPT, <*-percentage> is now considered computationally independent, and registering a custom property with the universal syntax and a CSS-wide keyword as the initial value now fails (w3c/css-houdini-drafts#1076), which was already implemented for @Property but not CSS.registerProperty(). WPT also expects var()-containing value to be invalid with the universal syntax, but the reason is unclear so it is not implemented, for now.
Right now the steps for registering a custom property appear to allow the initial value for registered properties that use the universal syntax definition ("*") to be a CSS-wide keyword (such as
inherit
,initial
, etc.). Since these values are treated specially in custom properties I think they probably shouldn't be allowed in the initial value of a registered property.I think it's possibly also allowed in the non-universal case as well, depending on how you interpret "computationally independent".
I think these rules should throw an error in step 4 if the value given is a CSS-wide keyword. (It's possible they should also reserve
default
which is disallowed from being a<custom-ident>
, but is not a CSS-wide keyword.)The text was updated successfully, but these errors were encountered: