Tag name in CSS selector (e.g. div#id): how is it read? (Left to right or right to left?) [duplicate] - performance

Question

This question already has answers here:
In which direction do selector engines read, exactly?
(2 answers)
Closed 6 years ago.
So I came across a couple of articles on CSS optimization:
http://csswizardry.com/2011/09/writing-efficient-css-selectors/
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS
Apparently CSS is read from right to left. That means that div table a is read like: first all a elements on the page are retrieved, then all table elements that have an a in them (right?), then all div elements with both of those in them (right?).
My question, which I couldn't find an answer to anywhere, is: how is a CSS rule like div#div_id parsed? Do first all elements with the id "div_id" get parsed, and is a filter then applied to fetch from that bunch of #div_id elements all div elements? Or are first all div elements parsed, and is a filter then applied to fetch everything with the id "div_id"?
The first article I mentioned says that the recommended order of efficiency in CSS is: #id > > .class > tag > rest. But what about tag#id?
To clarify: I like to type div#div_id just to have it clear for myself that #div_id applies to a div element without having to look up the HTML to find out which element's styling I'm looking at, but I wouldn't want to use it that way if it costs me much of my website's performance .What would be the recommended way of writing the rule then? Should I drop the tags in my selectors? Is it really that expensive?
The answer
The answer would be, as jbutler483 says: leaving the tag name out is faster. If you want to have clarification on what element you're styling, don't use div#my_id but #div_my_id. If you don't care that much about performance, you could still go with the div#my_id, but it will be a bit slower (but you can ask yourself if it will really impact your application that much).

Answer 1

Ok, I think you've gotten a little confused.
In your example, you use:
div table a
So i'll use that.
Pretty much, that could look like this in your html
<div>
<table>
<a>
//styling applied here
</a>
</table>
</div>
or something else like
<div>
<div></div>
<table>
<tr>
<th>hi there</th>
<th>
<a>i'm an a tag!</a>
So, looking at that:
div table a
will be
div table a
^ ^ ^
| | |
| | a child
| |
| parent
|
grandparent
This means that you'll be styling any 'a' element that is a child/descendant of a table, which, in turn, is a descendant of a div element
so, in your other example:
div#div_id
you would be styling all id's of div_id in which have a div as a parent.
BTW looking at your example, I would like to point out that (in case you didn't know):
the id attribute should be unique
an <a> attribute shouldn't be used directly within a <table> element (instead nest it within a th or td tag)
If you wish to style multiple elements (of varying types), it would be more efficient to create a class, and use that instead
Answer after Clarification:
Your
div#div_id
In HTML, since the id is meant to be unique, it will look up 'all id's' with the specified id.
It will then check if it is a div element.
This seems to be a bad example, as obviously some (older) browsers will only look for the first id, and return it instead of checking the whole webpage for any 'duplicate' id's.
With your id's being unique, you could then drop your tag as it will be left redundant/ no use
Summary
So, an example of this extended conversation in the comments:
if I wanted to style a single div (and still know it was a div that i was adding styling to), i would use the naming convention of:
<div id="my-div-to-style">
^
|
[the word 'div' here could be anything]
in my css i would write:
_ this word must match the
/ id i used above
|
#my-div-to-style{
//styling...
}
If i wanted to add the same styling to multiple div elements (with the scope to add it to others), i would instead use a class:
<div class="myDivStyle">
and then use:
.myDivStyle{
//styling...
}
in this last example, I would not be restricted to just styling divs, so i wouldn't include this in my naming:
<div class="myStyle">
<a class="myStyle">
<table class="myStyle">
.myStyle{
//styling for any element I want
}

Answer 2

As you say, rules are parsed right to left, the same applies here.
Although duplicate id values are not valid, it is up to the browser to decide whether to accept and parse them, the below (in Chrome) for example, renders the first and last elements with red text.
Demo Fiddle
div#test {
color:red;
}
<div id='test'>text</div>
<span id='test'>
text
</span>
<div id='test'>text</div>
In modern browsers you may want to be less mindful of selector resolution performance and instead look to obtain valid CSS adhering to best practices, keeping selectors as short and concise as possible.

Answer 3

What about tag#id? The second link you mention contains the answer.
Don’t qualify ID rules with tag names or classes
If a rule has an ID selector as its key selector, don’t add the tag
name to the rule. Since IDs are unique, adding a tag name would slow
down the matching process needlessly.
Don’t qualify class rules with tag names
The previous concept also applies here. Though classes can be used
many times on the same page, they are still more unique than a tag.

Answer 4

You may learn more about your question here: css-tricks => efficiently rendering html
There are four kinds of key selectors: ID, class, tag, and universal. It is that same order in how efficient they are.
#main-navigation { } /* ID (Fastest) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (Slowest) */
#content [title='home'] /* Universal */
When we combine this right-to-left idea, and the key selector idea, we can see that this selector isn't very efficient:
#main-nav > li { } /* Slower than it might seem */
Even though that feels weirdly counter-intuitive... Since ID's are so efficient we would think the browser could just find that ID quickly and then find the li children quickly. But in reality, the relatively slow li tag selector is run first.