I have created a link and when I try to set the style;
a:visited {
text-decoration: underline;
color: #FF0000;
}
It doesnt seem to work. It works fine in IE. I have also followed the order; link, visited, hover, active.
Is this a known issue, or am I making any mistake?
It might have to do with specificity and the order that you have your selectors in. In general, when specifying link states, you should follow the "love/hate" principal:
:link
:visited
:hover
:active
Maybe you have the :hover or :active selector before :visited?
Download the Firebug or WebDeveloper plugin for Firefox and use it to examine the style of the link, say using Inspect, to see where the style is being set. You should be able to see what styles are being applied and from where.
i have heard it is to do with the security - so something under the firefox hood disables visited links from showing so that other software cannot inspect the active styles and figure out where a user has been.
that does sort of make sense, but they should make it an option, and they should also EXPLAIN TO PEOPLE THAT THAT IS WHAT THEY HAVE DONE and save us all some time.....
Go to Tools -> Options and check if Firefox is remembering your browsing history. If this option is unchecked then the browser cannot show you which links you have visited because you denied the browser that information, hence the reason why your visited links do not change color.
Because of security issues that Google/Bing/etc. will be glad to tell you about, only a short list of properties can be styled with the :visited pseudoclass. Text-decoration isn't one of them, though color ought to work.
Depending on what IE version the OP was using when s/he posted this question, the issue there may be incompatibility of IE, especially before IE8, with standards and with other browsers.
More information here (among other places): https://www.w3schools.com/cssref/sel_visited.asp
It's likely being overridden by another style. If you have the Web Developer toolbar installed you can see what CSS styles are in affect and where they came from by selecting "View style Information" from the CSS menu.
Related
I have a very odd instance in that my main Google Chrome browser is prioritising the wrong css.
I am using WordPress with Elementor and Astra on a Siteground Server. I have tried clearing both the browser cache, server cache etc...I even tried clearing Google Chrome cache via the settings.
The issue only happens on this Google Chrome Setup, works on another Chrome instance (including Incognito) and for Firefox and Edge etc.
This is the code that should be working
.elementor-button-wrapper .elementor-button:hover, .elementor-button-wrapper .elementor-button:focus {
color: #ffffff;
background-color: #062950;
border-color: #062950;
}
And this is the fallback style it is using:
.wp-block-button .wp-block-button__link, .elementor-button-wrapper .elementor-button, .elementor-button-wrapper .elementor-button:visited {
color: #062950;
}
The above code actually has a strikeout on it in the inspector but the right code is used when I tick to disable this code.
I have had this issue on Cloudways before when Varnish caching was being used.
Does anybody know off the top of their head what it could be and whether there is an underground way of purging the entire Google Chrome cache for a specific site? Many thanks!
So I found the problem which was really rather simple and probably so simple I didn't think to look.
The style was active for that element but crossed out in the Google Chrome inspector. It was bewildering why unticking an overridden style would fix the issue. The reason was that part of that style rule included the :visited (but it was classed as an inactive element).
Simply put, the browser history was the reason and I had to create an additional style to to offset the visited link from taking preference. I hadn't even considered whether the link was visited or not.
.wp-block-button .wp-block-button__link, .elementor-button-wrapper .elementor-button, .elementor-button-wrapper .elementor-button:visited {
color: #062950;
}
Example, it was the .elementor-button:visited that was creating this mess, and I was only look at .elementor-button-wrapper .elementor-button which was the active element.
I don't know if this will help anybody but considering other states beyond :hover is important when debugging odd issues like this!
on a certain website I would like to change the appearance of a certain link. The operator of said website did something to it so that it does not work the way it used to anymore.
(I'm moderately new to CSS, this much in advance.)
The link goes [website]/internal/main.php?action=menu&id=[some number]. So far I've been changing it with
a[href*="main.php?action=menu&id"] { font-size: 30px;}
but that does not work anymore. So basically 'select any link that cointains that string and change the fontsize to 30px'.
However it would be really helpful/convenient to be able to edit it. Any other links on the page can still be edited via the above CSS. After reading a little I thought adding "!important" would solve the problem, but it did not.
I was under the impression that no matter what the website 'does' that the user has full control over what the browser displays, as it should fetch the 'intended' thing from the server and THEN add custom CSS to it, effectively changing it.
To that end I've been using the Firefox AddOn "Stylus" to edit/change the appearance. Other similar programs also did not manage to change said links. (Stylish, StyleBot for Chrome). It is the same issue on both Chrome and Firefox. I have not tried any other browsers but i imagine it is the same there.
I'd be very thankful for any pointers in the right direction, explanations of where my understanding of the matter is wrong and/or solutions to this problem.
Thank you in advance
Most likely the original CSS definition for links on tha site is done for the different states a:link, a:hover, a:active and a:visited
So you should change your rule to
a:link[href*="main.php?action=menu&id"],
a:visited[href*="main.php?action=menu&id"] { font-size: 30px;}
And similar for the two other states
I am having a problem with IE 8 where the visited links color do not change in our application.
We don’t have this problem with IE6.
When using IE6, visited links changes its color if the link has been viewed before.
Our application works fine with IE6 but with IE8 the visited link do not changes its color.
For information,
I have cleared the history , unchecked the option "use Windows Colors" in the browser option. But the links in our application always remain unvisited.
Here is the CSS:
a:link {
color : #006000;
}
a:visited {
color : #3CB371;
}
Any help and suggestions would be greatly appreciated.
There is a security issue with the :visited style.
To describe it briefly, it is possible for a malicious site to find out what sites you've visited by having links to all the sites it wants to check for, and then just examining the colours of those links.
This issue got a lot of publicity about three years ago, and as a result IE and all the other browsers released patches that disabled the :visited style.
I couldn't find a link that was specific to IE, but here's a link from Mozilla describing the problem and their solution for it in Firefox.
Older browsers (IE6, IE7) will still support the :visited style, but IE8 and all other current browsers do not.
Some of them do support it as a user-configurable option, but defaulting to switched off, but very few users will have switched it on, so you can basically ignore that.
More recently, some browsers have re-enabled the style, but changed the Javascript getComputedStyle() function so that it ignores the visited style. This allows the end user to see the visited colour but prevents the potential for a hacker to find out the information. I don't think IE8 ever got this update.
I can style visited links with a:visited. I want to the same for links to pages I have in my browser favorites.
I wonder if Firefox has a pseudo-class for that.
Then I could style them with the addon "Stylish".
There's a good reason this doesn't exist: It can be used in conjunction with getComputedStyle to invade your privacy (using javascript to report what you may have bookmarked).
This was also a problem with the :visited selector and Mozilla rectified it:
http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/
I suppose they could do the same for :bookmarked or something, but as of now this doesn't exist.
I wonder if Firefox has a pseudo-class for that.
I could not find anything in this list of Mozilla-specific CSS extensions that does what you want, so most likely there isn't such a pseudo-class.
There is definitely no such pseudo-class in standard CSS, though, but I think you already know that since you're asking specifically about a Firefox extension.
I know, it's pathetic, but IT just got around to installing IE8 on my machine this morning. Right off the bat I came across a glaring issue and I've messed around with it for too long even though I KNOW the answer is staring me right in the face.
First off, here's the website: www.mchenry.edu
View it in IE8 and hover over the top banner image - see everything shift down? It's some type of text-decoration or border issue but I can't figure out which. In our test environment, I even tried to get real specific with
#banner p#img a:hover {text-decoration: none};
But that doesn't do anything. And what's even more annoying is that I can't get it to show up in IE6, 7, or FF, or Safari, or Opera, etc. Beating. Head. Against. Desk.
Thanks for any insight you guys may have.
Okay, let's see. This is where the developer tools come in handy.
Using the developer tools, I hovered over the image, and activated the "click to select" feature, as this maintains the "error". I clicked on this small area, and it highlighted the <p id="img">, which now had a height of 128.
Something is expanding the p by two pixels, and editing the source to remove the <a> removes the problem, so clearly, something in there is disturbing it. I'm not seeing what, and it doesn't help that I can't seem to affect the color of that small box.
However, we can do more: we can yank out parts of the CSS. I removed the CSS rules from Records.css one by one, and when a:hover was removed, the problem went away. Going deeper, removing the background-color from there, it stopped!
So, a simple fix is to assign the <a> element a new attribute: style="background-color: transparent".
Note that I didn't test this with any other browsers or versions, but I can't see that rule having affecting other browsers (in a bad way).
try this:
#img a:hover {text-decoration: none!important;}
I have just encountered this same bug under IE8 (version 8.0.6001.18702).
I also traced the problem using the IE8 Developer tools by turning off css statements until I found the one responsible. I an verify that having a background-color on a:hover causes the problem and overriding this with "transparent" does solve the problem.
Unfortunately if you do want a hover background color on your links there isn't a generalised solution - the best you can do is to create a class for "imagelink" which you apply to all your anchor tags which surround an img tag:
<img src="test.gif" alt="test"/>
Then you can use the CSS:
a.imagelink:hover { background-color: transparent; }
This should work around the IE8 bug for your image links whilst allowing you to keep your hover background color on other hyperlinks.
Not very elegant, but I didn't want to follow Jan's suggestion of using a meta tag to force IE8 to render as IE7 (there are lots of things IE8 does better than IE7 and I don't want to revert all the rendering to IE7 over this one issue).
I find it astounding that despite all the hype about IE8 being so much better than older versions we still find bugs of this nature: a colour choice causing a layout issue. Unbelievable. And yet this thread was started back in July last year - and the bug remains unfixed, with more and more developers having to waste their time identifying the problem and dirtying their code with workaround hacks to solve an IE-only issue. It's like IE6 all over again.. Hopefully the EU's imposition of a browser-choice screen into new Windows installs will help open people's eyes to all the proper web browsers out there.
Michael's analysis of the background style of the anchor tag being what triggers this bug in IE8 is spot on. But instead of working around it by adding a style attribute to all the anchor tags, you can tell IE8 to display your page the way IE7 does by adding this meta tag as the first tag inside the head tag:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
or by adding this line to .htaccess:
Header set X-UA-Compatible IE=EmulateIE7
to force IE8 into IE7 compatibility mode.