682318 - API to list matching & non-matching rules sorted by specificity

Status: RESOLVED DUPLICATE of bug 730280

(Core :: DOM: CSS Object Model, defect)

Description

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

In the style inspector (DevTools) we make attempts to calculate specificity using JS but have noticed that our calculations do not match the internal Fx value. It would make a lot more sense if we could expose CSS specificity through nsIDOMCSSRule as then we would be less prone to future bugs.

Comment 1

[Boris Zbarsky [:bzbarsky]]

A given rule can have many different specificities associated with it.

So what sort of API do we really want here?

And do we want it to be web-exposed or part of the inspector utils?  I'd guess the latter for a start.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The other option (maybe what's desired) is that the API that exposes the list of rules that matched also exposes the specificities with which they matched (since there it is unique).  Problem is, we don't currently have that information... though we need it for bug 561154.

Comment 3

[Mihai Sucan [:msucan]]

Ideally we'd have a way to retrieve an array of selectors from a single rule, and for each selector we need the associated specificity.

Currently we have JS code that takes the selectorText of a CSS rule and splits it up (for comma separated selectors) to build the array of selectors, then we calculate the specificity.

It would be a good start, indeed, to have this part of some chrome-privileged API. Exposing such API to the web brings additional complexities that would delay us from getting a working API for our devtools.

What sort of API:

- maybe given an nsIDOMCSSRule, a new method getSelectorsArray().
- getSelectorSpecificityScore(selectorText) so we can have selector1 comparable to selector2, using getSelectorSpecificityScore().

Another idea would be to have nsIDOMCSSRule .selectors as a list of nsIDOMCSSSelector objects (invented the name now), for each rule selector. Each nsIDOMCSSSelector would hold .specificity which would be the score, and .text which would be the selector text. In the future other API could be added to these "selector" objects.

(just some thoughts)

Thank you!

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

What is it you're attempting to do with this API?

Comment 5

[Mihai Sucan [:msucan]]

(In reply to David Baron [:dbaron] from comment #4)
> What is it you're attempting to do with this API?

We are displaying the list of selectors that match (or not) the highlighted element. Selectors are grouped by properties of their rules. So the user sees "color" and dives into this property view to see the list of selectors coming from rules that change the color property. We sort selectors by their matched/unmatched state and by their specificity.

Here's an older screen shot from the Style Inspector:

https://bug672748.bugzilla.mozilla.org/attachment.cgi?id=548143

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

So, in a nutshell, having selected an element we need to be able to list it's selectors sorted by specificity (highest first).

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

So what you want that inIDOMUtils::getCSSStyleRules doesn't give you is to include the rules that *don't* match in the list sorted by specificity?

Comment 8

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Yes, exactly

Comment 9

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Just to be clear, here is a more complete list of the things we need:
1. The rules that match in the list sorted by specificity.
2. The rules that do not match in the list sorted by specificity.
3. Failing 1 or 2 we would need access to the specificity score relating to a rule and an HTML node.

The problem is that if we reimplement the specificity calculation in JS then when :not(), :-moz-any() etc. are fixed then users will not see exactly what is happening under the hood.

Comment 10

[Steve Roussey (:sroussey)]

Great, two years ago I wanted to add this to Firebug:

http://code.google.com/p/fbug/issues/detail?id=2222

Once this is done, we will finally be able to do it! :)

Also blocks an issue with showing the user agent css since that css tends to have 20 selectors and then a tiny rule, all of which takes up way too much space and makes Firebug looks like a big mess compared to Chrome.

Comment 11

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Because this bug appears to now be more about items 1 & 2 from comment 9 than it's original intent I have logged bug 730280, which is more specific to our needs.

Comment 12

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Because the new bug is more concise than this one I am closing this as a dupe.