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.
Related
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.
I'm using Eric Meyer's Reset CSS, and all hyperlinks "hover" (you know, act like the cursor is hovering over them) if the cursor is horizontally-adjacent to said hyperlinks, not necessarily hovering over the text of the hyperlinks themselves.
This is probably the doing of the Reset CSS, however I am not sure how to fix this, I'd figure it out eventually, but I'm hoping someone here can provide a quick fix.
Also, where should the Reset.CSS be in relation to my main.CSS? Should it be on the line above or the line below main.CSS for priority in the HTML file? That might be an issue as well.
Thanks!
It is usually a good idea to reset your styles first, using reset.css at the very top of everything else, and then add you own styles.
The basic rest.css from Eric Meyer does not touch anchors (a) in any way, so I suspect your own code (or browser) for strange mouseover-behaviour. Use your browsers developer tools (usually opened up by pressing F12) and check the styles applied to the element.
Based on what I understand, as far as I know this can be caused in two cases.
First, if your markup is like this <a><li>some hyperlink</li><a>, and your CSS is like this:
a:hover{
....
}
OR
your markup is like this <li><a>some hyperlink</a></li> <- this is correct way but your CSS is like this:
li:hover{
...
}
so you might want to check your markup, I don't think so that this is caused by your CSS reset.
I am using the background-color property in CSS media type print.
The problem is that Google Chrome does not show background-color or background-image in print preview.
How can this be solved?
Chrome supports control of background colour / image printing via CSS. You can set the following CSS property on elements whose background should be printed:
-webkit-print-color-adjust: exact;
Normally of course, this is determined by browser settings - but Chrome allows web designers to determine how backgrounds are printed on a per-element basis...
Notes:
Requires Chrome 17 or higher.
The background of the body tag is not printed.
Thanks to Cron’s Web Tech Blog, where I first spotted it:-
http://blog.crondesign.com/2011/11/print-css-backgrounds-in-google-chrome.html
Also, this leads to some background (no pun intended!) info regarding the feature:-
http://code.google.com/p/chromium/issues/detail?id=107763
Hope this helps...
I tried for hours using the ideas suggested but none worked. I needed to use !important
Somehow chrome must be deferring to a different background-color statement.
background-color:red !important
I think the issue is not with your code, but with Chrome: there is no option to print background (images or colors) : see http://www.google.com/support/forum/p/Chrome/thread?tid=17a4ac343580c8d3&hl=en
With Firefox, the background images are not printed by default, but it can be activated in "Print... -> Page setup"
You can try the developer tools in chrome to check which css rules applied in your DOM element. That will help you debug and fix the issue.
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.
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?