Skip to main content

CSS Specificity


Many time different CSS rules overlap on one or more element. And some people always get confuse about, which rule will take higher priority then other and why? CSS Specificity is the answer of all these kind of questions.

As the name suggest, the CSS rule which is more specific to the element will take higher priority then other. Means something like “#some_id{}” will always take higher priority then “*{}” universal selector.  And if duplicate rules are define then the last rule will be applied to the element.

The following list of selectors is by increasing specificity:
  • Type selector (e.g., div) and pseudo-elements in selector (e.g., :after)
  • Class selectors (e.g., .some_class), attributes selectors (e.g., [type=”radio”]) and pseudo-class selector (e.g., :hover)
  • Id selectors (e.g., #some_id)

ID takes higher priority then Class, Type and Universal selector (Note: Universal selector has no effect on specificity, see below special conditions). 

If duplicate rules are given, then last rule will override the earlier one.

Some special conditions while deciding the selector specificity:
  1. No effect on specificity: Universal selector (*), combinators (+, >, ~, ‘  ‘) and negation pseudo-class (:not())
  2. Inline style always overwrite any styles in external stylesheets and it has highest specificity.
  3. “!important” declaration overrides any other declarations. Although has nothing to do with specificity, but it is a exception.

But some time use case become more complex then this, and we have to calculate the selector’s specificity accurately.

Calculating specificity

As per the W3C Recommendation, selector’s specificity is calculated as follows
  • Count the number of ID selectors in the selector (= a)
  • Count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
  • Count the number of type selectors and pseudo-elements in the selector (= c)
  • Ignore the universal selector

Selectors inside the negation pseudo-class (i.e  :not(x)) are counted like any other, but the negation itself does not count as a pseudo-class.
Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.


After calculating the specificity "div#div" has highest specificity then others, so this rule will be applied,
1. div         - specificity: 1
2. div#div  - specificity: 101
3. #div       - specificity: 100

Some Examples for specificity calculation:

* { }                       /* a=0 b=0 c=0 -> specificity =   0 */
li { }                      /* a=0 b=0 c=1 -> specificity =   1 */
li:first-line { }           /* a=0 b=0 c=2 -> specificity =   2 */
ul li { }                   /* a=0 b=0 c=2 -> specificity =   2 */
ul ol+li { }                /* a=0 b=0 c=3 -> specificity =   3 */
h1 + *[rel=up] { }          /* a=0 b=1 c=1 -> specificity =  11 */
ul ol { }            /* a=0 b=1 c=3 -> specificity =  13 */ { }            /* a=0 b=2 c=1 -> specificity =  21 */
style=””                    /* highest specificity        =1000 */
p { }                       /* a=0 b=0 c=1 -> specificity =   1 */
div p { }                   /* a=0 b=0 c=2 -> specificity =   2 */
.sith                       /* a=0 b=1 c=1 -> specificity =  10 */
div p.sith { }              /* a=0 b=1 c=2 -> specificity =  12 */
#sith { }                   /* a=1 b=0 c=0 -> specificity = 100 */
#sith:not(div) { }          /* a=1 b=0 c=1 -> specificity = 101 */
body #darkside .sith p { }  /* a=1 b=1 c=2 -> specificity = 112 */


Popular posts from this blog

ERROR: Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

Recently I found this issue while writing code snippet in "JSFiddle". And after searching, found this was happening because of new feature added in "Chrome 46+". But at the same time Chrome doesn't have support for "allow-modals" property in "sandbox" attribute.

Chromium issue for above behavior:

To make it work you have to add "allow-scripts allow-modals" in "sandbox" attribute, and use "window.alert" instead of "alert".

<!-- Sandbox frame will execute javascript and show modal dialogs --> <iframe sandbox="allow-scripts allow-modals" src="iframe.html"> </iframe>

Feature added: Block modal dialog inside a sandboxed iframe.

Feature working Demo page:

JavaScript [ExtJs3]: EditorGridPanel Read-Only (dynamically)

Many time we face the scenerio where we have to make the editor grid read-only dynamically.

Ext.override(Ext.ux.grid.CheckColumn, { editable: true, onMouseDown: function (e, t) { if ( { e.stopEvent(); var me = this, grid = me.grid, view = grid.getView(), index = view.findRowIndex(t), colindex = view.findCellIndex(t), record =; if (!grid.isReadOnly && grid.colModel.isCellEditable(colindex, index)) { record.set(me.dataIndex, ![me.dataIndex]); } } } }); var grid = new Ext.grid.EditorGridPanel({ ... isReadOnly: true, //set to flag to make check column readonly ... }); //to make other column readonly grid.on('beforeedit', function () { return false; });

JavaScript [ExtJs3]: Total “Record” count in filtered store

There is two way to get record count from the Store
store.getTotalCount() This function depend on server response value. For accuracy of the value, property shell if return by the server.

Property name for the diff. reader:
totalProperty for JsonReader, totalRecords for XmlReaderstore.getCount() Will return you the number of record from the store.
Or if you have filter on the store, it will give you the number of filtered record.
But if you want to get the total number of record regardless filtering, Then it will be like this

var totalRecords = store.snapshot ? store.snapshot.length : store.getCount();
“snapshot” is the variable in “Store” which hold the actual data in case if you have applied a filter.