I don't know if it's a part of any standard, but at least two major browsers have implemented it:
:-webkit-any-link in Chrome
:-moz-any-link in Firefox
I can't find any documentation for it. I would like to know its purpose, browser support, and examples of usage.
:any-link is a new pseudo-class proposed in Selectors level 4, that matches all elements that would be matched by :link, :visited. From what I see, its main purpose is to simplify selectors that need to select any hyperlinks, since the naming of :link is misleading; it specifically means unvisited links only, rather than all hyperlinks (which makes it essentially the opposite of :visited).
For the purposes of :link and :visited, WHATWG HTML and W3C HTML5 both define a "hyperlink" as any one of:
An <a> element that has an href attribute. This excludes named anchors (that is, <a> elements without an href attribute but instead with a name attribute), which were used traditionally to mark anchors in a page, now superseded by the use of an id attribute on any element. See named anchors in HTML 4.
An <area> element that has an href attribute.
A <link> element that has an href attribute.
For example, consider a scenario where links in the page header should be colored differently from all other links:
body > header > a:link, body > header > a:visited {
color: white;
}
Notice the body > header part is duplicated across both selectors. This seems redundant, but is currently necessary in order to color links in the page header differently from the rest, but regardless of their visited state. This is because body > header > a is not specific enough which requires using !important to override anyway, and body > header > a:link troublesomely only applies to unvisited links.
With the :any-link pseudo-class, you can simply do this instead:
body > header > a:any-link {
color: white;
}
Specificity is exactly the same as with each individual half, so there should be no issues there.
Of course, since no browser implements it unprefixed yet, that won't work. As an alternative, considering you're most likely working with an HTML document anyway you can just use a[href] instead, which works in all browsers including IE7+ on top of also being equally specific:
body > header > a[href] {
color: white;
}
There's a much more elaborate explanation regarding the use of a versus a:link, a:visited versus a:any-link versus a[href] in this other answer of mine.
Like anything else that has a prefix in CSS, :-moz-any-link and :-webkit-any-link exist only for experimental purposes, so you shouldn't use them with your sites. Besides, even if you were to use them right now, you'd have to duplicate the rules themselves (and not just the selectors!) since browsers have to drop entire rules on unrecognized selectors, rendering them pretty useless in real-world code!
As of early 2013, no other implementations of :any-link exist that I know of. I'm unsure as well as to whether this was implemented by the respective vendors and then proposed for inclusion in Selectors 4, or if it was preliminarily specced before the vendors began implementing it, but I don't think that matters.
Speaking of which, be sure not to confuse the :-moz-any-link/:-webkit-any-link pseudo-class with :-moz-any()/:-webkit-any(), the latter of which is specced as :matches() instead (possibly to avoid naming confusion?).
In the Mozilla CSS Extensions document, :-moz-any-link is mentioned with the note “(matches :link and :visited)”. The link to detailed information is dead, but the apparent reason for using such a pseudo-class is the odd design of CSS as regards to links: :link matches unvisited links only, whereas :visited matches visited links. Using a single selector is useful in complex cases where you would otherwise need to write two complicated selectors that differ in one pseudo-class only.
They could use a[href], except that this would bind the selector to a specific element (and attribute) used to create links (which is a markup language issue).
Using Firebug and inspecting a link in it, you will see the following styles from the browser default style sheet:
*|*:-moz-any-link:not(svg|a) {
text-decoration: underline;
}
:-moz-any-link {
cursor: pointer;
}
The latter sets the shape of the mouse pointer (“cursor”) on all links. The former makes links underlined, except inside an svg element.
Related
Every example and stylesheet I've looked at uses a:visited to style links. Besides a:visited having higher specificity, shouldn't :visited be equivalent and simpler?
TL;DR: At the time of writing, you are completely correct; there is no difference between a:visited and :visited. However, using a:visited is best practice for future-proofing your code.
TL;DR EDIT: As of August 2016, the CSS4 Working Draft allows other tags to use :visited. There is now a functional difference between a:visited and :visited! Beware.
For web development languages today, specifically HTML5 and CSS3, you are right: there is functionally no difference between a:visited and :visited. Now, please take this with caution: web standards, elements, and user interface protocols are ever-evolving, meaning that in the future, it is possible that a new tag compatible with :visited may be introduced.
When :visited was introduced in CSS, the W3C CSS1 spec said:
In CSS1, anchor pseudo-classes have no effect on elements other than 'a'. Therefore, the element type can be omitted from the selector:
a:link { color: red } == :link { color: red }
HOWEVER, in the CSS2 spec, the behavior of the :visited pseudo-class was not restricted to just a tags:
The document language determines which elements are hyperlink source anchors. For example, in HTML4, the link pseudo-classes apply to a elements with an "href" attribute.
This means that it is up to the document language and browser to determine which elements are compatible with :visited. While the current industry standard states that for HTML, only a elements with an href attribute qualify, this may well change later down the line.
EDIT, August 2016: Looks like the CSS4 Working Draft has confirmed my suspicion; in the new spec, :visited can be used for other "link-like" elements, namely <area> and <link>. The spec says:
The :any-link pseudo-class represents an element that acts as the source anchor of a hyperlink. For example, in [HTML5], any <a>, <area>, or <link> elements with an href attribute are hyperlinks.
So <a>, <area>, and <link> are all treated as hyperlinks, and the spec says that :visited applies to all hyperlinks. So as of CSS4, you'll be better off including the a in a:visited.
According to Selectors Level 4 :visited applies to any hyperlink, which in HTML is the <a>, <area> and <link> elements when they have an href attribute.
A quick test for the link element shows that Firefox at least partially respects this:
Try http://jsfiddle.net/rfdzpjLo/4/ in FF or see below
link:before { content:attr(href); }
link { display:block; }
:visited { color: red; }
:link { color:green; }
<link href="http://stackoverflow.com/questions/27263128/why-not-visited-instead-of-avisited-for-links" />
<link href="example.net/lsjhuehbsi00ejjdus" />
Yes, but it won't be future compatible if a new tag is introduced that may be styled with :visited.
Closest proof I can find:
http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes
The document language determines which elements are hyperlink source anchors. For example, in HTML4, the link pseudo-classes apply to A elements with an "href" attribute. Thus, the following two CSS 2.1 declarations have similar effect:
a:link { color: red }
:link { color: red }
In theory it's the same for reasons already mentioned. On paper, a:visited vs :visited makes it explicit that the style only applies to anchors, and may potentially be faster: think of it as the browser needing to iterate through all a tags in the one hand side, and checking if :visited applies, vs doing the same for all tags in the DOM.
Imho though, the more important reason is that styles related to a tag, a pseudo-selector, a class and an identifier aren't necessarily applied in a consistent and predictable order from a browser to the next.
Suppose, for instance, this visited link:
<a id="foo" class="bar" href="...">visited link</a>
Then consider the following CSS:
#foo {
color: red;
}
.bar {
color: green;
}
:visited {
color: purple
}
There used to be a time where the link would appear red, green or purple depending on the browser. (Perhaps it's still the case; I haven't tested.) Because, some would treat #foo as more important than .bar (it's an ID vs a class) and both of these as more important than :visited for similar reasons. Some would treat #foo, .bar and :visited as if they had the same importance, as a property of the tag itself. Some might have treated #foo and .bar as equals but more important than :visited on grounds the latter is a mere pseudo class. And so forth.
Now, consider this CSS, which is the kind of stuff you might encounter in a stylesheet today:
a.bar {
color: green;
}
:visited {
color: purple
}
Even assuming that tags, ID, classes and pseudo classes are all treated equal, we still have a potential problem, in that a.bar can also be considered more specific than plain :visited by some browsers.
Ergo, you end up needing to specify a:visited in the declaration to ensure the behavior is consistent in all browsers -- and chances are there are still a few bad apples around that'll make you want to write a:visited, a.bar:visited just to be sure.
Once you've run into the problem a few times, force of habit kicks in and you'll end up always writing a:hover or a:visited.
:visited is a pseudo class selector used only for anchor link elements that matches when the href attribute of that anchor link has been visited in the past by this browser. It is meant to be useful feedback for a user, so they can tell the difference between links they have been to and links they have not.
REFERENCE
The syntax of a pseudo class is as follows
selector:pseudo-class {
property:value;
}
So you have to use a selector when using a pseudo class and since it supports only links, in this case, the selector would be a.
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.
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.
Here is my code:
.blue {
color:#6E99E1;
font-size:9px;
}
<span class="blue">::CLICK HERE:: to view our New Equipment inventory. <br /><br /></span>
I've somehow triggered something that prevented the <a> tag from inheriting color of parent <span>.
Just an addendum to the other responses, if you want your <a> tags to inherit the colour from their parent you can use
a {color: inherit; }
By default an anchor tag does not inherit attributes like color if an href attribute is present.
Check out the difference between these two on a page:
<span style=color:green>test</span>
<span style=color:green><a>test</a></span>
The following link is to the w3 c:
http://www.w3.org/TR/html401/struct/links.html#h-12.2
User agents generally render links in
such a way as to make them obvious to
users (underlining, reverse video,
etc.). The exact rendering depends on
the user agent. Rendering may vary
according to whether the user has
already visited the link or not.
.....
Usually, the contents of A are not
rendered in any special way when A
defines an anchor only.
This is an answer to the question as well as a reply to Kevin's answer and its comments.
Anchor tags do inherit color, linked or not. The only reason they don't in practice is because they already have their color set in the browser's default stylesheet. The same can be said for the underlining of the link (which, I presume, you didn't notice, because you actually want it or had already changed it yourself).
In Firefox, you can see this in Firebug if you toggle "Show User Agent CSS" (or you can have a look at Firefox's internal stylesheets directly. You can see the browser's defaults in Webkit's Web Inspector and Opera's Dragonfly as well. I don't think you can in IE.
I don't know of any site which has an overview of all browser's defaults. CSS2's "informative" HTML4 stylesheet as well as the YUI reset stylesheet would be a good starting point, but neither of them mention any (link) colors (the HTML4 stylesheet does mention the underline).
To find out which properties are inherited in general, you can use the CSS2 reference property index table (see the "Inherited?" column). SitePoint also mentions it in its CSS reference.
So if you want to make sure your link inherits its color from its parent instead of from the browser's default stylesheet, you would ideally do something like this:
.blue a:link {
color: inherit;
}
You could set it for the different pseudo-classes separately (so :visited, :hover and :active as well), or for the a tag altogether.
However, IE6 and IE7 don't support the inherit keyword, so if you want to support them too, you'd have to set the color explicitly.
I think a doesn't inherit color by default. (certainly it has always worked that way on my sites). Why not change
.blue {
color:#6E99E1;
font-size:9px;
}
to
.blue, .blue a{
color:#6E99E1;
font-size:9px;
}
Firebug will show you exactly which style rules are applied to which elements. It's perfect for this.
(A non-CSS possibility: Do you have link/alink/vlink attributes on your <body> tag?)
Edit: Duh, silly me, the others have it right - <a href> doesn't inherit colour. But Firebug is still a good tool for this kind of problem (even if I'm not. 8-)
In addition to firebug (which should be your first port of call), the IE developer toolbar will also tell you where a given style is sourced from, just in case IE - shock, horror - should be different.
You need to explicitly set the color of the links to override the default blue color.
You are likely seeing the a:visited colouring. Try this:
.blue, .blue:link, .blue:visited {
color:#6E99E1;
font-size:9px;
}
Is there any way with CSS to target all inputs based on their type? I have a disabled class I use on various disabled form elements, and I'm setting the background color for text boxes, but I don't want my checkboxes to get that color.
I know I can do this with seperate classes but I'd rather use CSS if possible. I'm sure, I can set this in javascript but again looking for CSS.
I'm targeting IE7+. So i don't think I can use CSS3.
Edit
With CSS3 I would be able to do something like?
INPUT[type='text']:disabled that would be even better get rid of my class altogether...
Edit
Ok thanks for the help! So here's a selector which modifies all textboxes and areas which have been disabled without requiring setting any classes, when I started this question I never thought this was possible...
INPUT[disabled][type='text'], TEXTAREA[disabled]
{
background-color: Silver;
}
This works in IE7
Yes. IE7+ supports attribute selectors:
input[type=radio]
input[type^=ra]
input[type*=d]
input[type$=io]
Element input with attribute type which contains a value that is equal to, begins with, contains or ends with a certain value.
Other safe (IE7+) selectors are:
Parent > child that has: p > span { font-weight: bold; }
Preceded by ~ element which is: span ~ span { color: blue; }
Which for <p><span/><span/></p> would effectively give you:
<p>
<span style="font-weight: bold;">
<span style="font-weight: bold; color: blue;">
</p>
Further reading:
Browser CSS compatibility on quirksmode.com
I'm surprised that everyone else thinks it can't be done. CSS attribute selectors have been here for some time already. I guess it's time we clean up our .css files.
Sadly the other posters are correct that you're
...actually as corrected by kRON, you are ok with your IE7 and a strict doc, but most of us with IE6 requirements are reduced to JS or class references for this, but it is a CSS2 property, just one without sufficient support from IE^h^h browsers.
Out of completeness, the type selector is - similar to xpath - of the form [attribute=value] but many interesting variants exist. It will be quite powerful when it's available, good thing to keep in your head for IE8.
w3 reference
browser support reference
You can do this with jQuery. Using their selectors, you can select by attributes, such as type. This does, however, require that your users have Javascript turned on, and an additional file to download, but if it works...
Sorry, the short answer is no. CSS (2.1) will only mark up the elements of a DOM, not their attributes. You'd have to apply a specific class to each input.
Bummer I know, because that would be incredibly useful.
I know you've said you'd prefer CSS over JavaScript, but you should still consider using jQuery. It provides a very clean and elegant way of adding styles to DOM elements based on attributes.