New API for devtools to know when a CSS declaration is "useless"

RESOLVED DUPLICATE of bug 1306054

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 1306054
2 years ago
2 years ago

People

(Reporter: pbro, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
This idea came out of a discussion with jet, dbaron, heycam, birtles and others while talking about better layout debugging tools in devtools.

This specific idea is to let authors know when a given CSS declaration is "useless" and why. One example would be when `width:200px;` for instance is set on an inline element.

Right now, devtools is already able to show warnings in the inspector for declarations that are invalid.
For instance if you have `foo:bar;` in your CSS, then the inspector will display a warning icon next to it.

We would like to do the same for declarations that may be valid, but aren't actually used (or dropped, not sure what the correct term is here). The difference with invalid properties however is that we'd like to show a *reason* here. This would be the really nice added value of this feature. As you'd hover over the warning sign, you'd get a tooltip explaining the reason for the declaration to have been dropped.

Right now, we use DOMUtils.getCSSStyleRules(node, pseudo) to list the rules that apply to an element, and then, for each property in those rules, we check DOMUtils.cssPropertyIsValid(name, value) to know whether they are valid.

So, from a devtools standpoint, having an API like DOMUtils.cssPropertyIsUsed(name, value) would do the trick nicely, but whether a property is used or not depends at least on the node it is applied to, so maybe that is something that DOMUtils.getCSSStyleRules(node, pseudo) should return instead?

Opened to discussions on the exact API.

This would be really really useful for users and also something no other browsers have.
One thing to note is that most of these "useless" things are related to computed values, rather than declarations, although you might like to tie them back to their declarations somehow in the UI.

I think that many of the things we want to expose here are just a bunch of pre-defined interactions between computed values on a given element, including the "width on inline element" case.  Some examples:

  * fill-rule:nonzero has no effect on this element since it's not an SVG shape element

  * width:200px has no effect on this element since it is an inline element

  * top:100px has no effect on this element since it is not a positioned element

  * list-style-image:url(...) has no effect on this element since it is list-style-type:none

Some examples of things where it's related to the declaration could be restrictions on properties used in particular pseudo-elements or pseudo-classes:

div::first-letter { display: none; }
a:visited { font-size: 50px; }

  * display:none is useless on ::first-letter since it is not in the limited set of properties
    that can be set on ::first-letter

  * font-size:50px is useless on :visited since it is not in the limited set of properties that
    can be set on :visited

I think for all of these cases, we may as well just add the support for detecting these in the devtools code rather than have an API for it, since it's just a big list of checks of combinations of values.


For more complicated layout related "useless" declarations, like "margin-top:10px has no effect on the position of this element since the margin is collapsing with these other elements and that gives you a margin bigger than 10px anyway", it may or may not be worth doing something like we discussed and adding annotations to Gecko's reflow code that indicates when certain values are being ignored.  I think it would be difficult to come up with something comprehensive, but it may be possible to expose good enough information from there.  It might be best to start with a list of things you would like to see exposed, and then we can see how difficult it would be to expose that directly out of the reflow code, or if instead it'd be easier to just write JS code to detect these cases.
(Reporter)

Comment 2

2 years ago
I was reminded of this while reading this SO question: http://stackoverflow.com/questions/40412065/how-to-trace-this-computed-css-value-in-firefox-inspector

The person is trying to set height:20px on an inline element and devtools is not helping at all. The person has been trying all sorts of things like height:20px !important; max-height: 20px; min-height: 20px; and nothing seems to work.

Of course the element is inline, so nothing will work, but devtools could tell the user instead of just showing height:20px in the ruleview and height:90px in the computedview.

(In reply to Cameron McCormack (:heycam) from comment #1)
> I think for all of these cases, we may as well just add the support for
> detecting these in the devtools code rather than have an API for it, since
> it's just a big list of checks of combinations of values.
Alright, if it's going to be a big list in the end, I agree that there's no use putting that list in Gecko. We can just maintain it on devtools side. 

> For more complicated layout related "useless" declarations, like
> "margin-top:10px has no effect on the position of this element since the
> margin is collapsing with these other elements and that gives you a margin
> bigger than 10px anyway", it may or may not be worth doing something like we
> discussed and adding annotations to Gecko's reflow code that indicates when
> certain values are being ignored.  I think it would be difficult to come up
> with something comprehensive, but it may be possible to expose good enough
> information from there.  It might be best to start with a list of things you
> would like to see exposed, and then we can see how difficult it would be to
> expose that directly out of the reflow code, or if instead it'd be easier to
> just write JS code to detect these cases.
Agreed. Let's go through these one by one and decide then.
(Reporter)

Comment 3

2 years ago
Let's try and make the list of "useless" properties as comprehensive as possible. Here's a first attempt: https://github.com/captainbrosset/useless-css-properties
Feel free to contribute.
(Reporter)

Comment 4

2 years ago
Alright, we've decide this was going to be built in DevTools, so let's make it a duplicate of bug 1306054. I'll add a comment over there.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1306054
You need to log in before you can comment on or make changes to this bug.