I'm developing some changes to a page and the current CSS rule is a:focus { color: red }. We don't want that for a page. We just want the focus to do nothing at all. I don't want to override it with a:focus {color: black} to keep it as black (as this then interferes with hover). I just want it to be more like a:focus {color: unchanged}
You might be able to use color:initial instead. It isn't supported in IE, but that's not such a big thing anymore.
Also try all:revert or all:unset. I don't think this is completely cross-browser compatible so maybe try all 3 together.
I would use color:inherit to return it to a normal value, which is what the color property does anyway in elements. It inherits them from parents. "inherit" erases the current assigned value on your element and says "just pass through me the text color every other element inherits and uses". So the text looks like any other text color you are using. Inherit is also supported across all browsers, including Internet Explorer.
Some browsers may assign special colors to anchor element "psuedo-classes" like "focus". But for focus its not so common as the others. If you think you might be needing to see that special color return then you can try "color:revert" (for non-IE browsers only) on an element using the "a:focus" psuedo-class. This should reset an anchor element BACK to its "psuedo-class" browser default focus color, if it exists. But I would not trust that.
To manage resets and defaults, I always assign my psuedo-class anchor elements a custom text link color in my "reset" style sheet so they start with a basic color shared across every browser and version. When I need to return my links back to those values, its very easy to then create selective styles to reset them.
Related
I am trying to hide the autofill style for a password input field that comes in via the user-agent-styles.
When inspecting the element, the computed styles show that the color coming from the user-agent-style is being overridden and #fff is being applied, but the actual computed style is still the one coming from the user-agent.
Any idea on how to get rid of this?
Here is the CSS I am using to try and override it:
.password {
border-right: none;
background-color: #fff !important;
}
#MainContent_txtPassword:-webkit-autofill, input:-internal-autofill-
previewed, input:-internal-autofill-selected, textarea:-internal-autofill-
previewed, textarea:-internal-autofill-selected, select:-internal-autofill-
previewed, select:-internal-autofill-selected {
background-color: white !important;
}
I found an answer that works for me! See https://webagility.com/posts/the-ultimate-list-of-hacks-for-chromes-forced-yellow-background-on-autocompleted-inputs
I had initially come across https://css-tricks.com/snippets/css/change-autocomplete-styles-webkit-browsers/ but that only works for opaque backgrounds, and not transparent ones. The webagility article includes a nice hack for transparent backgrounds too.
To summarise both the articles, the solution I applied is:
input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus,
textarea:-webkit-autofill,
textarea:-webkit-autofill:hover,
textarea:-webkit-autofill:focus,
select:-webkit-autofill,
select:-webkit-autofill:hover,
select:-webkit-autofill:focus {
-webkit-transition-delay: 99999s;
}
The reason this works is because chrome applies autocomplete styles via a css transition. If you delay all transitions on that input, the styles will never be applied.
This behaviour is seen in Chrome only (it is not in Firefox, I didn't test Edge or others). Chrome applies a pale yellow background (#E8F0FE) and black text to all autofilled inputs. This user agent style for autofilled text has hard-coded priority in Chrome's rendering since Chrome version 74. This behaviour is intended by the Chrome developers.
In Chrome, these hard-coded styles will override anything you can set yourself in the document or via Javascript. In the original question, Style Inspector shows the OP's background-color: white !important style as having precedence over the user agent style input:-internal-autofill-selected. Style Inspector is wrong to show that: it looks like it does not know that the user agent style for autofilled text has hard-coded priority.
I replicated the OP's issue in a (codepen). Note that I even tried to update the input:-internal-autofill-selected user-agent style in the document's own CSS, with the !important suffix. Even with that in the CSS, Chrome still uses the original, hard-coded user-agent style. This codepen also shows you that none of the following methods will be effective to override the user agent style in Chrome.
use CSS with greater specificity
add style to the element in HTML
use an event in Javascript to change the element's style properties (for example backgroundColor) after data is entered
This has been reported to Chrome as a bug. The developers' response is WontFix, citing a security concern. Chrome devs don't say what the security concern is, but I guess it is that a malicious site could create HTML with hidden input boxes (no border, and background and foreground colours matching the page background) and gather some auto-filled data without the user's knowledge.
This "WontFix" attitude is not a great solution. It annoys designers who want to control the appearance of input boxes. The OP wants a pure white background and Chrome changes it to #E8F0FE which is maybe not a big deal, but it's way worse for designers who want to use a dark background. How hard would it be for Chrome to check programmatically that the page has styled the input box with high enough contrast to be visible to the user? Chrome has also not fully solved the security concern, because a malicious site can hide an input box in some other way: it could be outside the visible screen area, or covered by a different page element.
I had a similar problem attempting to style a select option element's background colour when :checked.
I'm using pseudo elements to add checkboxes to a select element where multiple selections are allowed and didn't want to whole row showing as being selected.
I found that changing to another colour had no effect over the User Agent Stylesheet (Chrome) but using a gradient as the background did.
option:checked {
background: linear-gradient(0, #fff, #fff);
}
I've the following problem, I'm trying to change the color of the text of a "< li>" element, in joomla menu. I give the menu a link to css selector called blueMenu, this is my CSS regarding the class:
.blueColor {
color: blue;
}
However this doesn't change the color of the text, on the other hand if I change "color" with "background-color" the background of the text becoms blue. Any idea what may causing the problem?
You dont give much information, but it might be that the li has a child element inside that its overwriting the li styling, make sure you using the style on the last child.
You can also force it with !important;
.blueColor {
color: blue!important;
}
This really much depends on your template.
As already said, reasons can be inline-styles, or may more "distinct" declarations.
If you just specify the class like you did in .blueColor this will be treated with a lower priority as e.g. li.blueColor or to get even more clear both with be treated with a lower priority as e.h. #someId.andClass .subElementClass li.blueColor a.thisIsWhatIsReallyBlue
This is more about CSS specifications than a Joomla-Problem though.
You might check the style that is really applied by just launching your Development-Tools of your webbrowser (for Chrome simply press F12 or right-click on the element and inspect the element directly)
The CSS-Section on the right side might tell you about what really makes the item become blue ;)
Oh, and just a note:
As already mentioned you can use !important to "force" the styles to be applied, but if this is not absolutely necessary, i'd suggest to find the way to override this style on a clean way, since !important, if used to often, might result in a complete mess of your stylesheet.
regards
I'm not familiar with joomla but it may be inserting an inline style to whatever element you're trying to style. Right click on the element and use inspect element (firefox) or just inspect (chrome) to see if any styles were applied.
It'll look like <div class="" style="color: blue;">
I've been using Chrome for a long time now and I've never (well not that I can recall) come across CSS definitions in the Style panel that are faded. The selector hasn't been defined else where.
Example:
(Edit: Just to be clear, I'm not referring to the user agent stylesheet)
I can't figure out why it is faded and what this means. The definition appears to be editable but any changes to the values do not persist (i.e. as soon as I click off, it reverts back to original value) and has no effect on the web page.
I couldn't find any reference to this in the documentation for the tool. Can any of you kind folk shed any light on this?
Rules that are faded are not applied to the element.
Take a look at this example
<!-- HTML -->
<div>
<span>Test</span>
</div>
/* CSS */
div {
color: #F0F;
margin: 15px;
stroke: #FFF;
float: left;
}
If you open dev tools, you will notice that margin and float are faded, color and stroke are not. That is because span element inherited style rules from its parent, but only color and stroke rules are inheritable.
The "faded" styles are ones that are not applied to the selected tag. So in your screenshot, you have an h1 rule which is normal colored -- that one is applied to whatever element you have selected -- and you have an .SubHeader h1 rule that is not being applied to the selected element.
You'll sometimes see this if you dynamically add a CSS rule (the + button in the chrome dev tools) but modify the selector so it doesn't apply to whichever element you have selected.
It means that the rule has been inherited:
http://code.google.com/chrome/devtools/docs/elements-styles.html#computed_style
These are the stylesheets that are applied automatically by the browser.
You can see this by the description: user agent stylesheets.
You can disable this in the setting in the lower right corner by checking Show user agent styles. Now the styles won't be shown in your CSS panel (but are still being applied!)
EDIT:
i misread your question, the dev doc says the following about dimmed rules:
Note: If you edit the selector so that it will not match the selected element, the rule will turn dimmed and obviously, will not be applied to the element. You should rarely need to do this.
Your screenshot looks like this could have been the case.
I'm inspecting an h2 element on a web page using Google Chrome's element inspector and some of the CSS rules--which appear to be applied--are grayed out. It seems that a strike-through indicates that a rule was overridden, but what does it mean when a style is grayed out?
For me the current answers didn't explain the issue fully enough, so I am adding this answer which hopefully might be useful to others.
Greyed/dimmed out text, can mean either
it's a default rule/property the browser applies, which includes defaulted short-hand properties.
It involves inheritance which is a bit more complicated.
Inheritance
Note: Chrome dev tools "style" panel will display a rule set, because one or more rules from the set are being applied to the currently selected DOM node.
I guess, for the sake of completeness, dev tools shows all the rules from that set, whether they are applied or not.
In the case where a rule is applied to the currently selected element due to inheritance (i.e. the rule was applied to an ancestor, and the selected element inherited it), chrome will again display the entire ruleset.
The rules which are applied to the currently selected element appear in normal text.
If a rule exists in that set but is not applied because it's a non-inheritable property (e.g. background color), it will appear as greyed/dimmed text.
here is an article that give a good explanation - (Note: the relevant item is at the bottom of the article - figure 21 - unfortunately the relevant section doesn't have a heading) -http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art033
Excerpt from the article
This [inheritance scenario] can occasionally create a bit of confusion, because defaulted
short-hand properties; figure 21 illustrates the defaulted short-hand
properties of the font property along with the non-inherited
properties. Just be aware of the context that you're looking at when
examining elements.
It means that the rule has been inherited, but is not applicable to the selected element:
http://code.google.com/chrome/devtools/docs/elements-styles.html#computed_style
The pane contains only properties from rules that are directly applicable to the selected element. In order to additionally display inherited properties, enable the Show inherited checkbox. Such properties will be displayed in a dimmed font.
Live example: inspect the element containing the text "Hello, world!"
div {
margin: 0;
}
div#foo {
margin-top: 10px;
}
<div id="foo">Hello, world!</div>
Michael Coleman has the right answer. I just want to add a simple image to go along with it. The link that he included has this simple example: http://commandlinefanatic.com/art033ex4.html
The HTML/DOM looks like this...
The Styles Pane in Chrome looks like this when you select the p element...
As you can see, the p element inherits from its ancestors (the divs). So why is the style background-color: blue grayed out? Because it's part of a rule-set that has at least one style that is inheritable. That inheritable style is text-indent: 1em
background-color:blue is not inheritable but it's part of the rule-set that contains text-indent: 1em which is inhertiable and the developers of Chrome wanted to be complete when displaying rule-sets. However, to distinguish between styles in the rule-set that are inheritable from styles that are not, the styles that are not inhertable are grayed out.
This also occurs if you add a style through the inspector, but that new style doesn't apply to the element you have selected. Usually the styles shown are only those for the element selected, so the grey indicates that the style you just added doesn't select the element which has focus in the DOM navigator.
It means the rule has been replaced with another rule with higher priority. For example stylesheets with:
h2 {
color: red;
}
h2 {
color: blue;
}
The inspector will show the rule color:red; grayed out and color:blue; normally.
Read up on CSS inheritance to learn which rules are inherited/have higher priority.
EDIT:
Mixup: the grayed out rules are the unset rules, which use a special default stylesheet that is applied to all elements(the rules that make the element renderable, because all styles have to have a value).
When using webpack, any css rule or property that has been changed in the source code is grayed out when the page reloads after a rebuild. This is really annoying and forced me to reload the page every time.
The new version of chrome developer shows where it is inherited from.
I'm answering long after the question already has many correct answers because I encountered a different case of having a block of CSS code greyed out and uneditable in Chome DevTools: The block in question contained U+200B ZERO WIDTH SPACE characters. Once I found those and removed them, I could edit the block in Chrome DevTools again. Presumably this might happen with other non-ascii characters as well, I haven't tried to figure that out.
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;
}