Improve CSS error message for invalid @property
Categories
(DevTools :: Inspector, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: nchevobbe, Unassigned)
References
(Depends on 2 open bugs, Blocks 1 open bug)
Details
If you have the following (invalid) @property :
@property --a {
syntax: '<length>';
inherits: true;
/* not computationally independent, because it relies on the value of font-size on the element */
initial-value: 1em;
}
@property --b {
syntax: '<length>';
inherits: true;
/* not computationally independent, because it relies on the value of a custom property. */
initial-value: var(--a);
}
@property --c {
syntax: '<length>';
inherits: true;
/* initial value not matching specified syntax */
initial-value: red;
}
The CSS warning we get in the Console is the same for those 3, and it's: Ruleset ignored due to bad selector, which is really not helpful.
Ideally, the warning should indicate the name of the registered property that failed, which of this declaration is not valid and why. So with our 3 cases, something like:
@property --a wasn't registered. initial-value is not computationally independent (font size)@property --b wasn't registered. initial-value can't use var()@property --c wasn't registered. initial-value does not match specified syntax
We could also have better errors for other things than initial value:
@property --x wasn't registered, missing "syntax/inherits/initial-value" field
Depending on how we can shape the error message, we could even have the property name in a specific field, so we could consume those in the console, and show the properties that weren't registered in the @property section, as well as show the message in the variable tooltip when the non-registered property is used
| Reporter | ||
Comment 1•1 year ago
|
||
Zach, would you know:
- where this error is emitted from
- if we could shape it differently
- if there are other cases that lead to a property not being registered that we could highlight?
Thanks!
Comment 2•1 year ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #1)
Zach, would you know:
- where this error is emitted from
- if we could shape it differently
Sure, that will just require propagating PropertyRegistration::validate_initial_value, error instead of throwing it away. Similar propagation was done for syntax field errors in bug 1833540.
- if there are other cases that lead to a property not being registered that we could highlight?
Currently, initial values with font/line-height relative units, var() or env() references, or CSS-wide keywords all result in PropertyRegistrationError::InitialValueNotComputationallyIndependent. Does that work, or are you looking for a way to differentiate between reasons for computational dependence?
For the first piece, propagating initial value errors, I opened bug 1916584.
Updated•6 months ago
|
Description
•