Order by CSS Specificity

Question

My main goal is to try to reorder a CSS style block based on specificity. I previously had helped from SO and I managed to produce this function. See gist.

Here is an example:

function specificity($selector){
// https://gist.github.com/2774085
}

$compare = function($a, $b) use ($specificity) {
    return $specificity($a) - $specificity($b)
};

$array = css_array();

uksort($array, $compare);

The above has been working great until I came across this CSS:

html, body, body div{
    background: transparent;
}
body {
    background-color: #D96F02;
}

This gets reordered into this:

body { // 1 point
    background-color: #D96F02;
}
html, body, body div{ // 4 points
    background: transparent;
}

However, this isn't how the browser applies the CSS.

I think my specificity function may be missing the importance of order of CSS rather than ordering based on selector specificity? Is this true?

Update

I think what I should do is in my compare function, I should always add an extra points of say 10 because specificity isn't just based on selectors its based on the order of the selector too. So something like this:

 $compare = function($a, $b) use ($specificity) {
        return ($specificity($a) + 10) - $specificity($b)
    };

How does this look and how do I determine number of points to give in this case!?

Wynne

isn't background shorthand by default more selective? have you tried it with background-color:transparent? – Bronnie

@Bronnie are you saying that I should be ordering even at the CSS property level? I think the browsers only order by selector and then apply the CSS properties, right? – Wynne

Hmmm interesting problem :) Firefox extension Firebug has that solved but for one element right (inspect function). Try figuring out how they did it. Starting point, maybe code.google.com/p/fbug/source/browse/branches/firebug1.10/… – Enterostomy

Can I ask why you're trying to do this? What's the use case? – Adal

@Adal I am basically trying to create a better CSS inliner. I've used many others but they all have their faults. I'm trying to create a bullet proof one. The last step that I have now is how to consider selector order, I can calculate specificity but how many points should I give for order? – Wynne

idk man. i ran your css through this specificity calculator and your scores are correct: la.unm.edu/~bjudd/IT152-CSS/resources/specificity.php – Bronnie

@Bronnie my specificity calculations are correct. However, because I am reordering the CSS based on the specificity. I need to consider the original order they cam in. Do you see what I mean? – Wynne

You're never going make a bulletproof "CSS inliner" unless you completely understand how CSS and browsers handle this. If you just guess (+10 to specificity?!), it won't be robust. The spec: w3.org/TR/CSS2/cascade.html. – Adal

I disagree that your specificity calculations are correct. What you show as 4 points should actually be calculating three separate specificity ratings of 1, 1, and 2. The comma's make it three different css selectors in one line, not a combining selector like html > body > div or some such. – Aretina

@MatejB: It's precisely because it does it on a per-element basis, just like how browser engines do it when matching rules. – Topsyturvy

Answer 1

The problem should go away if you serialize

html, body, body div{ 
    background: transparent; 
} 

as separate rules, as if they were written in the following manner:

html{ 
    background: transparent; 
} 
body{ 
    background: transparent; 
} 
body div{ 
    background: transparent; 
} 

The semantics is a bit confusing, but basically you are judging an entire declaration based on independent selectors that have been combined into the same rule set.

Re your update: specificity is not affected by selector order, i.e. the rules below have the same specificity. The last rule will take precedense rendering in blue, unless you re-arrange the rules rendering in red:

<style>
    #container span {color:red;}
    div #content {color:blue;}
</style>

<div id="container"><span id="content">Hello world!</span></div>

Polyphony

And neither is specificity affected by how "close" the combinators and selectors are to the actual element that is matched, because there is no such notion of proximity in selectors. – Topsyturvy

@BoltClock: this is somewhat confusing when applicable to child selectors a>b being no more specific than descendant selectors a b; child selectors just "feel" more specific (after all, by definition a child selector would normally mach a smaller subset of elements than a descendant selector) – Polyphony

@o.v. awesome answer. This is exactly what I implemented a very good way for my problem to go away! Thank you for this! :) – Wynne