I'm curious what the difference is b/w E#myid vs. #myid (E is any element) given that there can only be one element with #myid on a page?
It must be a bug/mistake of you that #myid has no effect on the input element. It works fine for me.
As you changed your question:
Image you have two different documents that both use the same stylesheet. In one document a DIV element has the ID “foo” and in the other document a SPAN element has the same ID. You can then use the following stylesheet to style both element different:
#foo {
color: #FFF;
}
div#foo {
background-color: #F00;
}
span#foo {
background-color: #0F0;
}
Both elements would then have the same font color but a different background color.
They have different specificity.
http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
The two selectors have different specificity. Rules given in a more specific selector will override rules given in a less specific one.
The specificity rules are really easy. Whenever there is a conflict (two or more rules setting different values on the same element), the following rules are consulted in order:
1) What 'space' does the rule live in? A rule in a higher 'space' automatically wins against rules in lower spaces:
a) Set by the user's stylesheet, with !important
b) Set by the author's stylesheet, with !important
c) Set by the browser's stylesheet, with !important
d) Set in a style="" rule
e) Set by the user's stylesheet, without !important
f) Set by the author's stylesheet, without !important
g) Set by the browser's stylesheet, without !important
2) How many #ids are in the selector? Selectors with more #ids automatically win against selectors with less (assuming they tied in rule #1).
3) How many .classes or :pseudoclasses are in the selector? Selectors with more .classes automatically win against selectors with less (assuming they tied in the previous rules).
4) How many plain elements are in the selector? Again, more is better.
5) Finally, how far down in the document is the rule? Later rules override earlier rules, if they are tied on all previous categories. This applies within a document (at the bottom of your CSS file vs at the top) and between documents (any rules in the second <link>ed css file are 'later' than the rules in your first <link>ed css file).
Understanding specificity can help you write simpler CSS. I almost always start my selectors with the closest #id that I can, because it simultaneously limits the spread of the selector to exactly the elements that I want, and automatically overrides any 'global' css rules I may have set in the document.
The difference is that in different pages you could have different elements using that ID. Why you would do that, is beyond me, but it could be needed for (just an example) a div on some pages taking the same attributes as a span on other pages.
Different browsers will give you different and strange results on non specified corner cases. Some browsers allow for multiple elements sharing the same id, others don't. It even changes with different versions of the same browser. Without knowing wich browser you are using, it's harder to replicate the bug, but I recommend you to test your css on several browsers.
Along with the other folks points about ID not necesarily being unique on a page...
It is possible to have one ID applied to either of N different elements (eg <UL Id=MyList> or <OL Id=MyList>). Then you could have different bits of javascript to handle the various elements (ie. a bit of code to handle UL, a different bit of code to handle OL).
Not saying whether or not that's would be a good design... just saying that it's possible.
Edit: what I mean is that the server side could generate a page with either an <OL> or a >UL>... not both at one time. Think dynamic web page. And again... I'm not saying one way or another if this is a good design... just that it IS POSSIBLE.
Related
Lets imagine very simple case:
div.className{}
vs
.className{}
Which option is faster and why ?
.className{} is faster in downloading, because of smaller size of the css file.
It is also faster when rendering page, because it is not necessary to look for div elements.
A guideline from google:
Avoid qualifying ID and class names with type selectors. Unless
necessary (for example with helper classes), do not use element names
in conjunction with IDs or classes.
Avoiding unnecessary ancestor selectors is useful for performance reasons .
One very important difference between div.classname and simply .classname is in something called selector specificity. It is a set of rules which defines which selector gets more weight once the browser starts going through all the selectors that potentially have influence on a particular element.
ne of the most basic rules of CSS is that selectors can be redefined in a way that whatever definition comes last and has influence on a particular element its the one that is going to be used (the sole exception being when using !important which always takes precedence).
Now in the above example redefining the .class selector should actually hide the text but instead its still visible. How is that possible if we said that latter rules always take precedence? Its because the div.classname rule has a higher specificity that .box since it actually gets points for containing both an element (div) and a class selector (.class) in its selector declaration (div.class).
Of course the div.class rule will be applied only on a div element but since class selectors are often reusable pieces of code there is plenty of situations when they are used on divs.
Although the rules in the official W3 specification are not that hard to understand they are sometimes pretty hard to remember. That's why I would like to recommend an excellent article on CSS selector specificity which can be found here.
In my opinion selector specificity is by far the most important thing to master when it comes to tracing inheritance problems with CSS stylesheets.
For Example
Find some more info
Follow Up
I've noticed that a lot of css style recipes are often stated like this:
div#id_name {
blah: blah;
}
But since IDs are unique, what's the point of sticking "div" in front of #id_name? Is there any advantage over the following snippet?
#id_name {
blah: blah;
}
I would argue that the latter is superior because you might decide to make the id_name element into something besides a div.
This is primarily done to advance specificity and to hint the document as to what type of element #id_name is.
First, specificity:
Specificity determines which styles are actually applied to your element. The more specific you are in calling your element out, the more priority that block of properties takes over another.
For example:
Given HTML
<div id="id_name">
Look at this blue text!
</div>
With CSS
div#id_name {
color: red;
}
#id_name {
color: blue;
}
Results in
This will render a div with red text as opposed to blue text. This is beneficial when writing a framework if you want to guard your styles from being arbitrarily overwritten by local styles.
Secondly, hinting:
Oftentimes, CSS is an afterthought. It's a shame, too, as it's gotten increasingly more powerful and has taken many of the responsibilities previously reserved for client-side scripting languages like JavaScript. There is no implicit inheritance in CSS, rather it's explicit via a long declaration.
What I'm talking about with this is that you don't see
div {
.my-class {
/* RULES! */
}
#my-id {
/* RULES! */
}
}
as a part of CSS unless you're using a precompiler like LESS or SASS. Hinting a document with the element name instead of only the id or class allows for much greater readability for not only future you, but any collaborators you may have on the project.
And finally:
Sometimes it just doesn't make sense to not add a an element guard to your rule. If I have a rule that sets things like height, width or padding, I wouldn't want that same rule applied to a span. I would rather see it fail loud than silent to prevent rules being applied that have no place being there. It can cause messy and unexpected results given the exact scenario you described.
In addition, there's no guarantee that #id-name won't be re-used on a later page for an element that is not a div in the scenario you gave. So there's that, too.
Using ID's have a very strict specificity issue. Realistically, according to the standards, you can only use an ID once in any given HTML document. That doesn't mean you can't use ID's as styling selectors, though, it does come with dangerous pitfalls in larger projects. They're fine if you're using them as targets in Javascript. Go crazy.
ID selectors are very, very specific in targeting elements and in return, you end up with problems later down the line dealing with CSS specificity. Class selectors are reusable and have much looser specificity. Styling with ID's doesn't have anything different that a class selector doesn't have, so why use them if they're causing specificity issues? Read this and this. They are both fantastic articles on why ID's are not cool for CSS. It is a personal preference, but, making your CSS very specific is a front-end disaster in all real-world cases web development.
So, to answer your question properly, adding div at the start of and id selector, like div#id_name means you can only apply that id to a <div> element. You couldn't add it to a <span>, or any other element for example, which is an insanely restrictive method of styling in CSS. If you just use #id_name, you can apply this selector on any element instead.
The only difference is that div#id_name has higher specificity. This is seldom relevant, and there are other ways to make a selector more specific. People may include the element (tag) name for documentation purposes, but then they take the risk that was referred to in the question: someone might change the div to, say, p and forget to modify the CSS selector(s).
When using the same CSS property in one rule set, in the case of needing to provide a fallback for browsers that don't support a property you may be using, like so:
body{
background: rgb(255, 255, 255);
background: rgba(255, 255 ,255, 0.5);
}
Do browsers that understand both of these declarations render the first, then overwrite it with the second? Or does a browser save itself the hassle and only render the latter?
Edit: I am aware that if a browser understands both declarations it will render the latter, but I want to know if the browser renders/draws the first into the viewport and then overwrites it with the second or does a browser work in a way that means it only renders the one declaration that is required, potentially saving itself resources?
I would expect modern (and probably old) browsers to parse the CSS rules supplied to it before rendering anything. Here's a screenshot from the Chrome profiler for both rules:
And here's another, for only the first rule:
As you can see, there are no extra steps involved when two different rules are present. If the browser was to render it twice, you would see another "Paint". (The slight reduction in paint time for the single rule is likely to be because I removed the rgba rule, so the browser did not have to take transparency into account).
the last of the 2 will be applied
To be more precise: the first will be applied, then the second.
It would be the same as having 2 identical selectors setting the background property.
The one most descriptive will be applied. If they are the same, the last declared will be the one applied.
The "C" in CSS stands for Cascading which means styles can add to or supercede preceding CSS rules. So the second declaration will override the first.
Browser handle this correctly. You can use that kind of rules.
For example, chrome will apply rgba, and IE8 will apply rgb.
Browsers in general apply the following algorithm:
for each element in the DOM tree
for each CSS rule
if rule's selector matches element
apply all declarations in rule
render
This is not how it works:
for each CSS rule
for each element in DOM tree
if rule's selector matches element
for each declaration in rule
apply declaration
render
That would be a huge performance problem.
It follows from the basic UA conformance requirements that browsers must first parse all CSS rules, then decide, by the principles set in the specifications, what values shall be used for each property of each element. There is no allowance for “incremental rendering” in the sense of applying part of the CSS code before reading the rest. And it would be very odd for a browser to deviate from this, as it would mean more work to implementors, more complaints from authors and end users, and no benefits.
In css, I have seen both div.selector and selector being used to define styling rules for a specific selector.
What's the difference between the two and what are the reasons I should consider when adopting one over the other when writing my own css files?
div.selector targets only div elements with a class of selector.
.selector targets ALL elements with a class of .selector not just DIVs
So prefix element with tag name if you KNOW that's the one you will be applying css to. The later approach is more generic and targets all elements with specified class. However, you should be specific whenever you can.
If you know only div elements will have .selector class, going specific is better in terms of performance eg div.selector rather than .selector which will look for all elements on the page but will eventually apply those styles to DIVs only.
div.selector is a more specific selector than .selector.
For example of you have this HTML:
Link
<div class="selector"></div>
The selector div.selector only matches the div where .selector selects both elements.
As mentioned so far, prefixing your class with its element name (ie: div.selector) will select only elements which are divs, but exclude anything else. With this in mind you can create classes which can be applied to multiple elements and/or target a single element.
In terms of readability, prefixing your classes can help you and your team identify what the element is from within the css. However in terms of general best practise and performance it is commonly advised that you try to refrain from prefixing your class and id declarations as it causes additional work for your users' browser engine.
By prefixing your classes (ie: div#selector or div.selector) your browser has to locate the class and then identify whether it is of the div type). Whilst the time required to do this might be negligible, I feel it's still worth mentioning.
Below are a few helpful links on the matter of performance and practice:
https://developer.mozilla.org/en/Writing_Efficient_CSS and
http://css-tricks.com/efficiently-rendering-css/
I didn't see anything on here about it with a quick search, if there is let me know.
Here is an example of a CSS selector I'd write.
div#container div#h h1 { /* styles */ }
div#container div#h ul#navi { /* styles */ }
div#container div#h ul#navi li.selected { /* styles */ }
I write all my CSS like. This allows me to stop from having styles floating around and I can technically re-use the same class name easily. For instance, I might use .selected on multiple elements across the site.
I also specify the element type (div, ul, etc) before the class/id unless the style is used for multiple elements. I also specify the element before id's even though there will only ever be one id because it allows me to know the element easily when reading my CSS. For instance I'll know right off the bat that em#example will most likely have a font-style of italic.
This isn't a question about CSS formating, it's about writing selectors.
I'd love to hear opinions on this approach, as I've used it for years and I'm reevaluating my stying.
Although it's somewhat off topic I also write my selectors like this for selector libraries (like jQuery for instance). Although I haven't looked into jQuery's internals to see if there is performance issue with specifying the element with an ID.
I think it really depends on what the selector is for.
Almost every site has one or a few style sheets that "skin" the site - fonts, text colour, link colour/hover, line spacing, and so on, and you don't want these selectors to be very specific. Similarly, if you have a component or element that's reused in many pages and always needs to look the same - like let's say the tags right here on SO - then it's going to be a pain to maintain if you use selectors based on the ID.
I would always use the ID in the selector if it refers to a specific element on a specific page. Nothing's more frustrating than trying to figure out why your rules don't seem to be working because of a conflict with some other rule, which can happen a lot if everything is classes. On the other hand, I think that nesting the IDs as you are (#container #h) is redundant, because the purpose of an ID is to be unique. If you have more than one element with the same ID on the same page then you can end up with all sorts of problems.
It does make the CSS slightly easier to understand when your selectors provide some idea of the "structure" that's being represented, but, to be honest, I think that goes against the idea of separation of concerns. The #navi might be moved outside the #h for perfectly legitimate reasons, and now somebody has to update the style sheet for #navi, even though nothing about it has changed.
A bit subjective as Darrell pointed out but that's my two cents.
While the question is a little subjective I have to say I agree with your thinking. I think defining the element before the selector is clearer when reading the code and it is less error prone.