Priority in CSS selector spec conflicts (vs vs class selector type)

Question

I learned about the priority of choosing from this tutorial . I find it difficult to understand the behavior of this in one case. I have an element in HTML:

<input class="top_bar_login_form_input" type="text" name="email" placeholder="Prijavno ime"> 

The problem is that the properties of another selector override the properties of the class.

As shown in the figure above, the class is overridden by a less specific selector. The element is selected by input[type="text"] , which is less specific than the class. The only reason for this behavior that I see is that the .inputbox class .inputbox also evaluated when determining the priority, even if it does not match the element.

Why does a type selector override a class selector?

Answer 1

TL answer DR

The first rule is more specific than the second, because it has both a type and an attribute for the selector and, therefore, takes precedence:

 input[type="text"] { } /* type + attribute for specificity */ .top_bar_login_form_input { } /* only class for specificity, so *less* specificity */ 

---

Longer answer

You think that the type="text" bit, which is an attribute selector, is more specific than a class selector, according to the specific MDN page :

The following list of selectors is an increase in specificity:

• Universal Selector Functions
• Type selector
• Class selector
• Attribute selectors
• Pseudo-classes
• ID selectors
• Inline style

The above quote was in an MDN article at the time of writing this answer.

Why is this misleading:

(Tanks to @BoltClock hints .)

The above only seems to be correct, but that is because you usually include an element in a selector (for example, input[type="text"] ) when executing an attribute selector. However, that is sneaky: the input bit matters.

Suppose we have the following markup:

 <input class="my-class" type="text" value="some value" /> 

In the following scenario, the input displays red :

 [type="text"] { color: green; } .my-class { color: red; } /* last rule matched */ 

If we change the rules in the script , the tab will display green :

 .my-class { color: red; } [type="text"] { color: green; } /* last rule matched */ 

This is due to the fact that both selectors have the same specificity. Now, introducing the input selector into the attribute rule will make one of them more specific, which can be seen in this scenario :

 input[type="text"] { color: green; } /* most _specific_ rule matched */ .my-class { color: red; } 

the W3 spec makes my head hurt, but it has information on why this works. See Also @BoltClock answer and comments in these code examples for information on how specifics are calculated.

Answer 2

In the first rule, your element corresponds to input[type="text"] . Although the .inputbox selectors .inputbox not match this, this does not affect the priority, because the list of selectors separated by commas is calculated only by the most specific selector in the list that corresponds to the element. If none of the selectors matches it, it is not taken into account at all.

The reason the first rule overrides the second is because the class selectors and attribute selectors have equal specificity . A selector of type input , accompanying (or accompanied by) an attribute selector, is the reason that it outweighs the selector of a single class:

 /* 1 attribute, 1 type -> specificity = 0-1-1 */ input[type="text"] /* 1 class -> specificity = 0-1-0 */ .top_bar_login_form_input 

Thus, the first selector is more specific than the second, and not vice versa.

If you qualify a class selector with a type, so you have input.top_bar_login_form_input , the selectors will be balanced, and your second rule will override the first.