What is the difference between a and a:link, and when do I use one over the other?
a:link is specifically for links that have not been visited. a applies to all <a> elements.
John Conde’s answer and comments to it describe well the meanings of the selectors, but to address the question as asked I think we need to add these:
The selector a:link is more specific than a. This is evident when you think about it, but it might be missed when considering the effects of several CSS rules that apply to an element.
If you want to set properties on links in general (e.g., the font face of links), using a is simplest if you can ensure that a elements without href attributes do not appear. (It has been common to set destinations for links using a elements with a name attribute, normally without an href attribute; the more modern approach is to use the id attribute on any suitable element.)
But in most cases, it is best to use both :link and :visited, to avoid the risk of styling a elements that are not links. You would then use :link, :visited {...} to set properties for all links and :link {...} and :visited {...} to set properties for unvisited links and for visited links separately (typically, different colors for them).
The difference between :link and a:link, apart from specificity, is that :link covers elements that are classified as links. Although currently only a elements can create links, this might change in a future version of HTML.
Related
pseudo-elements are like virtual elements, however it seems to me that many of them are more like classes than elements.
eg. ::PLACEHOLDER ::SELECTION ::FIRST-LINE ::FIRST-LETTER ::BACKDROP
Can someone explain to me how these are considered elements and not classes? They aren't creating any new elements, they are just applying a class in certain circumstances.
Pseudo-classes target an existing element when the state of it matches a condition.
You can target a and a:visited and they will match exactly the same "thing" when it is in the visited state.
Pseudo-elements target something that isn't an element in its own right. The :first-line of an element isn't event a complete DOM node.
I'm using Stylebot for Chrome to override some styling on a webpage I often visit. What I like to acheve is to hide elements in a list which contain links I already visited.
So i have a <tr> which has the class table-row and I want to hide all table-rows which contain a visited link (a:visited).
How can I do that?
You can't, not even with JavaScript. :visited is a special class that has privacy safe-guards bound to it. It won't return any elements in a DOM selector query. To do it with CSS, you would need the elusive ancestor selector, which doesn't currently exist. Even if it did, the same privacy safe-guards would probably prevent it from working.
See Selectors API, Privacy Considerations for mor information.
You can't hide or change the list elements containing a:visited, but you can change their color.
I have a same problem, then I changed all their color to background's color. It's here, but you can't see them.
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/
The W3.org CSS specification states the following (emphasis mine):
The :link pseudo-class applies for links that have not yet been visited.
The :visited pseudo-class applies once the link has been visited by the user.
The two states are mutually exclusive.
This means that any style applied to the :link selector should only be applied to unvisited links. However, the only property for which this is true appears to be color. Applying font sizes, backgrounds and so on to the :link selector targets all links.
There is a note further down the page that states:
Note. It is possible for style sheet authors to abuse the :link and :visited pseudo-classes to determine which sites a user has visited without the user's consent.
UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently.
However, as far as I'm aware this only applies to the styles returned by Javascript, not to the display of the styles themselves.
Here's a JS fiddle showing the issue. Are the browsers deviating from the spec here, or is there something I'm missing?
The line,
"UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently."
Isn't applicable to styles returned by JavaScript only — it is exactly as it sounds. This means that browsers may just ignore certain properties on :visited entirely (which is what's happening in this case). Since the font-size would increase the size of the containing element, allowing the property to be different for :visited links would undermine the other security measures implemented by the browser.
A browser could choose to recalculate the dimensions without the :visited styles applied, if it wanted to. Naturally, this is more work and less performant than just disallowing certain properties. It's clear that the decision has been made based on the fact that there is no real need to use different font sizes, backgrounds, etc to differentiate between visited and unvisited links and, generally, most developers will stick to just modifying the colour slightly.
So no, they're not deviating from the spec, they're taking advantage of a permissible exception.
From what I understand from the spec, the browsers are treating :link like a to avoid the abuse on the visited status. Therefore with or without javascript, the style actually applied to all the links is :link, and the :visited only is overloading the style when visited.
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.