Don't report CSS errors when valid aliases have already been parsed in the same declaration block
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: emilio, Assigned: violet.bugreport, Mentored)
References
(Blocks 1 open bug)
Details
(Whiteboard: [layout:backlog:2019q2])
Attachments
(1 file)
Bug #1538101 fixed the "Multiple declarations for the same property", this is about the other fix.
When a CSS error is reported at parsing time, it eventually ends up in the DevTools web console when it gets opened (and if the right filter is turned on).
In bug 1528426, we're trying to make those errors more actionable for our users. In particular for the WebCompat team to diagnose problems quicker.
One part of this project is to reduce the number of errors displayed, in particular try to remove those that do not appear to be helpful.
Here's the case that we are trying to specifically address in this bug:
div {
-moz-user-select: none;
-webkit-user-select: none;
user-select: none;
}
In Firefox, the above will lead to an error reported for the user-select
property because it isn't a valid Firefox CSS property.
However because both -webkit-user-select
and -moz-user-select
are valid, the intended feature will still work, and the error will only be perceived as noise to the user.
Hence, the idea to avoid reporting this error at all.
Some conditions that would make this feasible:
- Only do it when error reporting is on, obviously, to avoid slowing everything down
- only do this within one declaration block
- only do this by checking already parsed declarations (no need to parse ahead of the current point)
- only do this for aliases.
In the use case provided above, it means once the parser reaches user-select
, if error reporting mode is on, it would check if valid aliases are already present in the block, would find out that yes, that is the case, and would not report the error.
Assignee | ||
Comment 1•6 years ago
|
||
Suppose that prop
is a property that we haven't supported yet, while its -moz-prop
version is already supported.
If an author specifies in a declaration block this property in its standard form
as well as multiple verdor specific forms, as long as -moz-prop
is specified, we
shouldn't report error for unknown property prop
. Because that's just noise.
Comment 3•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Description
•