For some reason, a ::selection declaration in my CSS simply is not working, it is always behaving as per the default (light blue background on Chrome, Mac).
The code works fine in a jsbin
::selection {
background: red;
}
Thus my assumption is something is being overridden somewhere in the project, but I can't find another declaration of ::selection anywhere in the stylesheet. I was wondering if there is any way to see this in the Developer Tools to try to pinpoint or debug why it isn't working in my project?
Even giving the CSS an !important declaration isn't helping.
edit
OK, I tried debugging further by adding:
<style type="text/css">
::selection, ::-moz-selection {
background: red !important;
}
</style>
to the footer of the document, and thus it turns out that one cannot combine these two declarations in one statement, which was mentioned by Chris Coyier in this comment:
I have a question: Why can´t you put ::selection and ::-moz-selection together and define a value for both of that? If you do that FF will ignore the values.
That’s a good CSS lesson! When a browser doesn’t understand any part of a selector, it ignores
the whole selector (even if they are comma separated). There are some
exceptions but mostly in old browsers (IE 7?).
So all is well and working again, but the question still stands I suppose, is there a way to see this declaration in the devtools somehow?
edit 2
Ok, of course, when the declaration sits on its own line, then it appears in the inspector.
edit 3
A very relevant SO question: Why isn't it possible to combine vendor-specific pseudo-elements/classes into one rule set?
I'm just surprised Chrome doesn't just still show the malformed declaration in the inspector rather than hiding it completely.
Try to check via inspect element.
Right click on web page
Select "inspect" option
In inspect element panel, there will be style appear in right hand side.
You will find your :selection declaration in it.
Related
We are working on redesigning our web-based application’s Front-end. We started with a PoC based on Extjs 6 and we are facing few compatibility issues.
These compatibility issues are related to IE8 and CSS, while it is mentioned on your website that Extjs6 is fully compliant with IE8.
CSS classes work perfectly with all Major Web Browsers (Firefox, IE11, Chrome...) but some do not on IE8.
This is an example of CSS not working properly under IE8:
Ext.create('Ext.button.Button',{
text:'Button Test',
cls: 'btnColor',
renderTo: Ext.getBody(),
});
.btnColor {
background-color: green;
border-color:green;
}
Works on IE11 :
But not on IE8 :
We would like to know if this is a known issue and is there a specific processing which allows us to handle this kind of needs.
Thank you in advance.
The element in your comment above is the wrong element - that's the inner element for the button; you want the class with an id something like button-1009 (it's going to be an anchor or div tag a few elements up in the hierarchy).
And as to why it's not working - there are going to be multiple CSS selectors that define the background colour. The default one, from ExtJS, is going to be x-btn-default-large. The full CSS class for the attribute is going to be something like x-btn buttonCls x-unselectable x-btn-default-large x-border-box.
Done like that, both the buttonCls and x-btn-default-large are equally valid choices - the browser must pick one to use. IE8 is picking the last one; other browsers are picking the first one. Neither is wrong - the ambiguity is in your code.
To fix it, make your CSS selector more specific. Try:
.x-btn.buttonCls {
background-color: green;
border-color:green;
}
This applies to buttons (which will be the only things that have the x-btn componentCls attribute) that have the buttonCls cls attribute.
The problem is JavaScript syntax.
IE8 and earlier are strict about trailing commas on arrays and objects.
Your line renderTo: Ext.getBody(), ends in a comma, but is the last item in the object. In IE8, this will fail to compile.
The solution is simply to remove that comma.
You can keep an eye open for theses kinds of things by running your code through a linting tool like JSHint or ESLint, which will flag this kind if thing up.
The answer of Sencha support team:
https://www.sencha.com/forum/showthread.php?305980-CSS-compatibility-issues-on-IE-8.&p=1118734#post1118734
This clarified a lot for me, it might help you :)
I have a page that works fine in most browsers(Safari, FF, Chrome, IE9) but on IE8 it won't show the body background color. It shows the Body bgcolor as white. In the Developer Tools, I see that it is overriding all the CSS and getting some background-color:#fff from somewhere.
I have my scripts (jquery 1.6.2) just before the closing tag as is suggested on the HTML5 Boilerplate (html5boilerpate.com) - not sure if not having the scripts in the head section causes this behaviour?
Anyone any ideas ? This is really weird.
A couple things to try.
Toy with the load order of your css files. Whatever is loaded last will be the style if you don't specify !important
Inspect your rendered html for inline <style/> blocks as they could be causing trouble and not show up in the style tab as a specific css file.
When in doubt target background-color directly as background will
sometimes be overridden by a background-color property
body{background-color:#e6e6e6}
If that doesnt work you could force
override it with body{background-color:#e6e6e6 !important}.
Background color not working on Internet Explorer (IE)
IE apply some filter before rendering web page . that's why some page colors changed .
you can add following line in your CSS file to avoid it.
filter: none !important;
Scanning through the blueprint css, it looks like the background color #fff is being set in two different locations: textarea and in a select box. Try removing the background color property from textarea and see if that helps, or even better comment out the blueprint references to see if that's causing the problem. Seems like 9 out of 10 times a property gets overridden in IE its because a third party library is assigning a diff property to the same element.
Chrome appends an stylesheet and it make a lot of problems for me. for example this selector
html>body, html>body * {background-color:#ffffff !important}
is one oe the things I can't override in my own styles. Anyone has a solution for that?
Though all browsers have a default stylesheet for elements, none of them set the background color as !important which wouldn't allow you to change it. What you show must be getting attached from elsewhere, not Chrome, but, without a link or the complete markup, anything we tell you would just be a wild guess.
I'm working with some CSS (from a Joomla template) like this:
div#logo {
-moz-background-clip: border;
-moz-background-inline-policy: continuous;
-moz-background-origin: padding;
background: transparent url(../images/head.png) no-repeat scroll 0 0;
...
}
I've looked up some of those -moz- properties and they seem to be assigned their default values, and if I turn them off in Firebug nothing happens visibly.
Would there be a reason to add them to a CSS file? Are they for an old version of Firefox perhaps?
I think what's happened is someone's set a background shortcut rule and then looked at the ‘computed style’ resulting from that shortcut rule in the DOM inspector. They've noticed that setting the style also sets Mozilla's background-clip, -origin and -inline-policy properties, and tried to reproduce these rules without understanding what they're for (namely a detail of Mozilla's CSS implementation, and potentially CSS3 in future).
Certainly changing -moz-background-inline-policy would only have any effect on elements that were display: inline (which div isn't by default), and changing the clip/origin properties around the border would only make any difference if the element actually had a border.
Get rid of them.
Chances are good that these properties don't need to be there. I'd suspect that they're included to ensure consistent rendering across different versions of Firefox. I guess the answer is, if you're seeing no difference from disabling them in the versions of Firefox you're interested in supporting, take them out.
background-clip isn't supported on current Firefox builds AFAIK, so the author has probably put them in preempting a problem (though that would be odd as they are all set to the default anyway, and they haven't included the opera or webkit prefixes...)
background-inline-policy is default as continuous in all Firefoxes, and background-origin is default as padding in them all too.
I'd say pointless code for this one.
If I turn them off in Firebug nothing happens visibly.
I'm not sure on those particular attributes, but have you checked that the browser isn't using a cached style sheet?
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.