I have the following CSS rule:
button.medium.fade-btn:hover:not([disabled]) {
color:red;
}
And HTML code:
<button class="medium fade-btn" disabled></button>
I need that hover effect works only when button is not disabled.
You haven't structured your selector properly
button.medium.fade-btn:hover:not([disabled])
In theory selects nothing, but is searching the children of button (which there are none) due to you putting it after the hover.
button.medium.fade-btn:not([disabled]):hover
Is the correct way.
Hover is the event so you want that happening on the not disabled button so it comes after everything else. Select the element and then use the hover as the last part. It may be easier to work with disabled: true/false as well.
Edit: This is either a browser compatibility problem, or your browser isn't liking just using disabled in the type selector. You should try using disabled=true in your selector and checking your browser version against the versions that :not() is supported in.
Related
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.
Take a look at this JSFiddle example in Chrome and FireFox.
In Chrome, the button should be a tad smaller than in FireFox. I have added the solution CSS from How to reset default button style in Firefox 4 + (which made the button a little smaller) but the button is still bigger in FireFox. The difference isn't very visible in this example, but have a look at how it affects my design.
Chrome:
FireFox:
As you can see the button is thicker in FireFox and is affecting the layout. Is there any way of avoiding this short of using styled divs in place of buttons?
Also, I'm using Meyer's CSS reset stylesheet
Firefox adds a special padding to inputs and button elements. This takes care of it:
button::-moz-focus-inner,
input[type="button"]::-moz-focus-inner,
input[type="submit"]::-moz-focus-inner,
input[type="reset"]::-moz-focus-inner {
padding: 0 !important;
border: 0 none !important;
}
I have concluded that the only way of ensuring that button/submit inputs remain identical across browsers is to recreate them using divs. Creating button inputs is easy since you can attach click events onto divs the same way as on buttons. Creating submit inputs is barely any harder. I solved it using jQuery by declaring a class, for instance 'submit', and adding the submit button functionality to all elements that have that class on load. Here's an exampe:
// On page load:
$('.submit').on('click', function(e) {
$(this).closest('form').submit();
});
Divs with the submit class that are not in a form will do nothing when clicked.
If you add tabindex="n" (where n is a number) to the element, it can also be focused using tab, just like a normal button. You can also style it to show that it's focused by using the :focus css pseudo-class. Then you could use space or enter to click the button with this event handler:
$('.submit').on('keypress', function(e) {
if (e.keyCode == 13 || e.keyCode == 32)
$(this).closest('form').submit();
});
(I wrote that last snippet in a hurry and haven't actually tested it. If you find an error in it or test it successfully please edit this answer accordingly.)
Have you by any chance set a line-height on the buttons on your page? You haven't on the fiddle, but line-height's other than normal, aren't accepted on firefox, and some other browser I believe - maybe IE, I'm not sure.
Have you tried a CSS reset? I dont have FF on this computer or else I would check if this works.
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/3.5.1/build/cssreset/cssreset-min.css">
css3 pseudo class :disabled
is this supported yet - thought it was but cannot make it fly in chrome
tried setting div.disabled = true;
tried setting div.endabled = false;
still no joy
if wish to show an entire DIV disabled, how can I darken "gray out" the entire DIV without knowing its background colors?
if the DIV is disabled, are INPUT's and A(nchor)s contained therein disabled as well?
my solution: cover the area of the page to be disabled with a translucent page with a higher z-index - this prevents any interaction with the page below.
I'm pretty sure you can't add a disabled attribute to a <div> tag, only <input />, <fieldset> and <command> tags. Maybe try adding a <fieldset disabled> around your <input /> elements instead?
Use rgba colours or opacity to give your disabled element(s) a faded out look, or hsl colours and reduce the saturation to give the disabled element(s) a black-and-white look
If you use <fieldset disabled> I think it will disable all <input /> elements contained within it.
Best answer to your question is in the definition of what a disabled element is.
http://www.w3.org/TR/2000/WD-css3-userint-20000216#pseudo-disabled
2.1.3 The :disabled pseudo-class
Similar to :enabled, :disabled allows
the author to specify precisely how a
disabled or inactive user interface
element should look.
It should be noted that most elements
will be neither enabled nor disabled.
An element is enabled if the user can
either activate it or transfer the
focus to it. An element is disabled if
it could be enabled, but the user
cannot presently activate it or
transfer focus to it.
:disabled is supported in Chrome - check jsfiddle sample: http://jsfiddle.net/easwee/zCVGV/3/
Quirksmode includes the :disabled selector in its table of compatibility.
According to that table, the style is widely supported in all browsers, except IE, where it only got added recently with IE9.
However, you can use the attr selector to do the same thing:
.myclass[disabled] { .... }
is (virtually) the same as
.myclass:disabled { .... }
with the benefit that it works in IE7 and IE8.
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.