I have a div with an ID:
<div id="main">
What's the correct (or difference) between
div#main {
and
#main {
Regards,
There is a great doco on using efficient CSS selectors, focus on rules with overly qualified selectors:
ID selectors are unique by definition. Including tag or class
qualifiers just adds redundant information that needs to be evaluated
needlessly.
Instead of just applying the style to an element with id main, your selector will re-qualify the element by checking whether or not it's also a div (in that order). To clarify: css selectors are evaluated right to left, unlike same selector syntax when used in jQuery etc.
Re pixelistik's suggestion that div#main is more specific than #main - yes, that is technically correct, however if you have to resort to this to raise a rule's specificity, chances are the structure of CSS you're working on is not as thought through as it should be.
#main matches everything with ID 'main', whereas div#main matches only <div> elements with ID main.
Ideally, you should never have two elements with the same ID, so realistically the two don't make a difference, but there's probably performance related issues regarding whether specifying div makes it find the result faster.
So difference is that:
When you write div#main style will be only for <div> element.
When you write #main it can be used as style for <div>, <span>, <p>, etc.
And what recommend is hard to say, every developer it has it different. So i using for example
span.<nameClass> when is nested in <li> for example.
#nav li span.href a {
...
}
I think it's used when you want that someone class with specific name can have only one element.
So when your write span#href it will works only for <span id="href">Simply dummy text</span> not for others. When you write #href it will works for <span id="href">Simply dummy text</span> or Link but both are correct when you also asking about this. Differences i wrote above.
Both are correct.
div#main is more specific than #main, which means that styles defined with the first selector will override the ones of the second.
Here's a good introduction to CSS specifity:
http://htmldog.com/guides/cssadvanced/specificity/
Related
I'm reading the book: CSS Mastery: Advanced Web Standards Solutions, and finding the css code inside is almost writed in this format:
elementName#idName
elementName.className
but, I'm used to write code ignoring element name with this format:
#idName
.className
so, I want to figure out what difference is between the two format.
Actually, I understand when should use type.class. And, I just want to find out the impact when I use type.class insead of only using .class when there is only one kind of tag here.
There must be some impact on performance.
Here's a real life scenario as when to use elementName and when to just use class or id name:
HTML:
<a class="blue">I'm blue and underline</a>
<span class"blue">I'm blue and bold</a>
CSS:
.blue {
color:blue //will make both <a> and <span> blue
}
a.blue {
text-decoration:underline // will make only the <a> tags underline
}
span.blue {
font-weight:bold //will make only the <span> tags bold
}
but remember when it comes to IDs you should not have duplicate IDs on your page anyway, this is more practical for classes
The difference between the two is that the first:
element.class
Is calling the element with that specific class.
And the second:
.class
Is calling all elements that contain this class
I think that the element inclusion in the selector is a holdover from days where some browsers required it (I think IE5 does, but I could be wrong). This is no longer necessary, and it does not make sense to include element selector for at least three reasons:
It slows the selector down since the element selector is slower than the other two -- especially id. Assuming selection is optimized so that fast selection is done first (e.g. the element with the matching id is found before the element selector is checked), there is still the additional step of checking the element selector.
It's not as extensible since you can't change the element without also having to change the selector. The implication is also that div.class would function differently than label.class, but I think that the class should be descriptive enough.
It changes the specificity of the selector. This could be very frustrating for some developers who may want to change <div class="foo"> from green to red:
div.foo { color: green; }
/* below is not applied since the above has higher specificity */
.foo { color: red; }
I've never heard an argument that supports type.class unless old browsers need to be supported.
I am facing issues writing a slightly complex CSS selector.
I want to select a div with "class" containing 'btn-group', but not 'open'
So I have something like;
div[class*='btn-group']:not([class='open'])
Now the issue is that there are around 5-6 elements that match the above condition. But I want to select the first out of that. How do I do the same?
Would prefer doing using nth-child..
What about: div[class*='btn-group']:not(.open):first-of-type?
[Edit]: This trick does not work if you have <div class="btn-group open"></div> as the first child... (as explained by #Jukka below) a JS-based trick will work, tho:
$("div[class*='btn-group']").not(".open").first()
.css({...});
// OR add a class
// .addClass("class");
http://jsfiddle.net/teddyrised/LdDCH/
try like this
div [class*='btn-group']:not([class='open']):nth-child(1) {
color:Red;
}
Using this you can select first child
Working Fiddle
You cannot. CSS selectors can’t be used that way. But if you provide a more specific HTML context (including containers for the div elements and a description of a pattern that the markup follows), there might be a way that works under some assumptions.
In particular, :nth-child and :nth-of-type only test whether the element is the *n*th child, or the *n*th child of its kind, of its parent. It does not take e.g. classes into account; the is no “nth of a class” selector.
When I studied front end dev at the university a few years ago, our teacher taught us to always provide the full (almost) parental
DOM hierarchy of the targeted element within our CSS selectors.
So in our web projects we had to write selectors like:
div#container div#content p.bread a.external { }
instead of just:
#container #content .bread .external { }
or (I see the disadvantages with class conflicts that may occur here)
.external { }
I personally write my selectors like
#container #content p.bread a.external {}
until I recently read an article saying that it should be avoided (but with no obvious reason why) and another article saying the same but that one was intended for jQuery selectors.
Was my teacher wrong and what is the right (fastest to parse and with most support) way of writing CSS selectors?
Practically speaking, you should use the least specific selectors you can.
div#container div#content p.bread a.external { } is a very, very specific selector. It is unnecessarily specific. There can only be one #content element, and it will surely always be within #container.
Write general rules. Don't attempt to target the precise DOM element. If a.external will capture the set of elements you want, use that. Otherwise you'll end up having to write p.bread a.external, p.potato a.external, p.olive a.external, etc, etc.
The difference in performance will be minimal. The benefits of general, reusable rules are large.
My 2 cents
Specific enough to target only what needs targeting (as others have said) is the general rule.
I agree with lonesomeday that "difference in performance will be minimal," but every added element in the chain is one more check to be done.
So Think About How to Reduce It
Are the ID's needed?
I disagree with Spudley that "there should never be a need to specify more than one ID in a selector." If your site is set up to have different display on different pages, and so #page1 #content is different than #page2 #content for displaying, then that is a legitimate case of two id's in one selector. However,
If all pages are #container #content then the drop the #container.
Also, if all p.bread elements are inside #content, then drop that selector also.
Are element names needed?
Is .bread intended to be used on anything other than a p? If not, drop the p.
Is .external intended to be used on anything other than an a (probably linking to an external site)? If not, drop the a.
Is the decedent relation of classes needed?
Is the .bread .external significant for display? That is, does .external exist outside of a .bread parent and does it change because of that parent? If so, then keep the relation. Otherwise, if the important thing is only the .external (no matter where it is), then that is the only selector you need.
Yes, your teacher was wrong.
From your example:
div#container div#content p.bread a.external { }
Given that an ID in a DOM document must be unique, there should never be a need to specify more than one ID in a selector. So the above selector that contains both #container and #content is immediately wrong simply by that criteria.
An ID is the most efficient and direct way to reference an element. Again, it's unique and instantly accessible, so there's no need to qualify it in any way, so adding div in front of either of the #container or #content here is redundant.
The other two parts of the selector p.bread and a.external are likely to be wrong, but it's not so clear-cut for these.
A selector only needs to specify the parts that are necessary to select the elements required and exclude any elements that are not required. In this example, if all .bread elements are ps or all .external elements are as then the element type a or p would be redundant and should be dropped. But without seeing your actual HTML content, it's not possible to be certain of this in the way that it is possible for the IDs because a given classname can legitimately be applied to multiple elements of multiple type.
Longer selectors such as div#container div#content p.bread a.external { } do take longer, yes. But rarely do they make any noticeable impact on the paint time.
Also, since IDs are (supposed to be) always unique, div#container and div#content should really just be #container and #content, respectively.
Elements are superfluous (or rather should be) when used with ID selectors (#), since your DOM should contain only unique IDs for elements.
It's also worth noting that classes should be used to bunch the styles of the same elements. In case you have two .bread elements in your DOM, but want them styled differently, you should consider using a different class name.
Both ways will work, and the impact on speed will probably be minimal. However there is no need to add the element to your rule, and I would encourage you not to as it helps your rules become more reusable - something you should always aim for.
You should also avoid using location to target elements. E.g. .sidebar h3. Instead, add a class to those h3s and target the class. This means you can reuse those styles you wrote elsewhere, just by adding the class. These are all concepts of Object Oriented CSS, and will help you write more efficient CSS by reducing the amount of duplicate code.
I have a file like
<div>
<div class="abc">
<div>
<!--some more divs inside-->
</div>
</div>
</div>
What I want to do is to apply styles only to the first div. I tried to use div:not(.abc, .abc *), div:not(.abc):not(.abc *), div:not(.abc), div:not(.abc) * but none of these worked. It would be hard to edit the html, because there would be many files to be edited. Also the code shown above appears in different places, so using > selector is not the solution... Does someone know how to do this?
You cannot reliably use the :not() selector in CSS for excluding an element and/or its descendants. The reason for it is explained in this answer (and some others that it links to):
You can't use combinators. This works in jQuery, but not CSS:
/*
* Grab everything that is neither #foo itself nor within #foo.
* Notice the descendant combinator (the space) between #foo and *.
*/
:not(#foo, #foo *)
This one is particularly nasty, primarily because it has no proper workaround. There are some loose workarounds (1 and 2), but they usually depend on the HTML structure and are therefore very limited in utility.
And since your markup is unpredictable enough that you cannot edit it or use the > selector, I'm afraid there's not much of a way out for you other than to either find a way to apply a class to your top div and use that class, as demonstrated by Fluidbyte, and/or use jQuery, as implied above.
I usually find it's easier to include what you need via a class then try to exclude descendant elements. See the fiddle here: http://jsfiddle.net/cLtHg/
That takes care of inheritance issues and is much more cross-browser friendly.
If you're really not touching the HTML, then a simple although dirty approach would be to apply styles to the first div and then remove them from subsequent divs, like so:
div {margin-bottom: 20px; border: 1px solid #ccc;}
div div {margin-bottom: 0; border: none;}
The major drawback here is that some styles in the child divs may get removed unintendedly. Depends on how they're styled in the first place.
Use :first-child with the ID or Class of its parent Element. If you are unable to catch the element using CSS, it is suggested to use Javascript or jQuery.
Have you tried :first-child or :nth-child() selecor?
in some CSS code I found out this type of selector
div#someid
Is this formally correct?
If the answer to (1) is YES, what's the need for the div selector before the #someid, shouldn't the id be unique in a valid web page?
Thanks!
Yes it's correct.
It might be because it makes the selector more specific. The more specific a selector it is the higher priority it is.
It is fine.
The stylesheet might be reused between pages which have the id on different elements
The explicit type provides information for the maintainer about the element
It makes the selector more specific, e.g. to override #other div.
The answer is they are the same but using the div in front of #id is superfluous and removing it does no harm while leaving it in only takes up space. Some may feel it makes the markup more readable, however, since it identifies the type of element the id is associated with.
I did read, once, that placing the div in front of the id may cause the browser to search through all divs first while just using #id does not but I'd have to look up that reference.
From what I understand, CSS will rank selectors based on how specific the selector is, if two rules apply to the same element,
ie
#someId{
color: black;
}
.someClass{
color: green;
}
And you had this div:
<div id="someId" class="someClass">
Then which wins? (There are rules in place to govern this particular example, I believe the ID would win anyway).
But say you had these rules:
.someClass{
color: black;
}
div.someOtherClass{
color: green;
}
Then I the second rule would trump it, because it's more specific.
However as David pointed out, ID's are generally rated a lot higher, so ID will win a lot of the time.
So there are two reasons I can see for using element#id selector
I) It's to trump some convoluted rule, ie div#canvas>div>div#main>div:last-child>div
II) So you know what element it is referring to, ie if your div had and id of "postcodeContainer" and you were trying to find it in the html file, it might be harder because you have to look at every element (unless you used your IDE's search/find option), where as div#postcodeContainer you know you are looking for a div element.
div#someid - select a div with id someid
#someid - select any type of element with id someid
One reason for having the tag selector is that it assumes some basic CSS, like it's a block tag with zero margins/padding.