Think of it like SQL EXPLAIN, but for CSS selectors.

cssExplain("li .item")
{
  "selector": "li .item",
  "parts": ["li", ".item"],
  "specificity": [0, 1, 1],
  "category": "class",
  "key": "item",
  "score": 6
}

The String selector input.

Parsed Array of selector components.

Computed Array of specificy values.

See W3C calcuating selector specificity.

Category index key selector falls under. Either 'id', 'class', 'tag' or 'universal'.

Modeled after WebKit's rule set grouping optimizations. CSS rules in WebKit are indexed and grouped in a hash table to avoid having to do a full test on the element being matched. So its better to have selectors fall under unique id or class indexes rather than under more broad indexes like tags. Selectors in the universal category will always have to be tested against every element.

{
  "id": {
    "about": ["#about"]
  },
  "class": {
    "item": ["li .item"],
    "menu": ["ul.menu"],
    "minibutton": [".minibutton"]
  },
  "tag": {
    "a": ["ul.menu a", ".message a"]
    "span": [".nav > span"]
  },
  "universal": ["*", "[input=text]"]
}

To match against <a class="minibutton">, the rule set would include class -> minibutton, tag -> a and universal which is [".minibutton", "ul.menu a", ".message a", "*", "[input=text]"].

See RuleSet::addRule for reference.

Hash used for indexing under the category.

1-10 rating. 1 being the most efficient and 10 being the least.

NOTE: Don't take this value so seriously

Array of infomational reasons for why the score was computed.

$ git clone https://github.com/josh/css-explain.git
$ cd css-explain/

Run tests

$ make test