Do you see the rectangle inside the blue div? It make no sense for me that Google Chrome render this rectangle. The page is only having a div with the class "sidebar" and the css is only this:
.sidebar{
background-color:#3756a0;
width:400px;
position:fixed;
top:0;
bottom:0;
left:0;
color:#fff;
}
I removed all extensions in Google Chrome, I've restarted my computer. Only me experiencing this render. I'm not sure how to fix this behavior. Any help?
Edit: I'm using MacOS Sierra v 10.12 and Chrome Version 53.0.2785.143 (64-bit) seem to be the last update possible. The problem appear also for me here: steemconnect.com see prntscr.com/crgo04 . It seem to be not easy to reproduce.
This question is going to have all shots in the dark I think but here are some things you could try:
Set * { all:initial; } to reset all style props to initial.
Switch display from inline to inline-block to block on the div / body.
Does the issue happen in Firefox? Safari?
Install Chrome Canary and see if it happens there.
Try going into the chrome devtools drawers and disable emulation and other options as shown here.
Had a similar problem a few days back. One guy from my team would see similar artifacts when he viewed the website we developed from Chrome running on his Sierra Macbook, while the rest of us who either had not upgraded or did not use macOS did not have this issue.
So, this is probably a bug of Chrome running on this version of the OS and it will get sorted eventually.
Also see this question.
I've had same problem. Calibration of colors in OSX helped out.
Preferences -> Monitors -> Colors
Related
Regular fonts look normal, but large fonts look jagged in Chrome (not in Safari or Firefox). I'm using a Macbook Pro running Mojave.
Example codepen
.large {
font-size: 300px
font-weight: bold
}
Chrome
Safari
Firefox
I've tried the recommendations in this SO post (enable-font-cache-scaling and accelerated 2D Canvas), but the issue remains.
Turning chrome://settings "Use hardware acceleration when available" OFF fixed it for me.
At first I was not able to reproduce the jagginess/blockiness, but I realized I was looking at it on MacOS [High] Sierra, and you specified Mojave. So I tried it there, and it is absolutely awful. I'm really surprised this escaped anyone's notice in testing. I'd imagine there will be an update to either Chrome or Mojave that addresses this soon.
I guess this is actually related to a change to the OS defaults; Apple apparently disabled sub-pixel font rendering in Mojave and passed it off as a "refinement". Sub-pixel rendering is handled by the GPU, hence disabling GPU rendering in Chrome "fixes" it. I guess you could also use the defaults write technique specified in the link I mentioned.
In any case: this is probably not something you can address in your CSS code, since it is related to user-local/machine settings.
Hi I am trying this example on my Chrome 46.0.2490.80 (64-bit Mac).
Seems neither following nor my code works:
cursor: pointer
Link to example which doesn't work for me.
where my codepen example comes from: CSS-tricks
Do you have the same problem? A Chrome bug? Thanks!!!
PS: Please don not down grade it if it works for you: works for you doesn't mean works for everyone, it's very basic logic.
I'm viewing this in Chrome 46 on a 64-bit Mac (El Capitan) and I'm not seeing any issues.
Try going to chrome://flags to see if this is a flag-enabled feature.
If it is not a feature that was specifically enabled, try disabling all of the flags:
click on reset all to default.
Works in my latest updated Chrome browser on a 64 bit-PC-Windows 7 Pro.
Yet your class name is spelled wrong for: .deafult
.idioma_es #logosFooter, .idioma_es #logosFooter li a {
background: url(../nImg/microsites/logos/logos_footer.png) no-repeat scroll left top transparent;
behavior: url(../../nJs/iepngfix.htc);
}
Result in Firefox:
Result in Internet Explorer 6 (Based on IE Tester for Windows):
the path of the .htc file is correct !
Any idea what i'm missing?
Don't test this with IETester. It's not completely reliable.
You should use a virtual machine, but you can quickly test a page with http://ipinfo.info/netrenderer/.
After Googling a little, I might have been a little unfair to IETester (though I still don't trust it).
http://www.my-debugbar.com/wiki/IETester/HomePage
Known problems and limitations :
CSS Filters are not working correctly in user mode : A solution is to launch IETester as admin user and CSS Filters will work.
You can try PIE - http://css3pie.com, that is working in IE6 too.
IE6 does not support the alpha channel for background images apart from in specific circumstances. There is no general fix, as there is for foreground images.
Look here: http://24ways.org/2007/supersleight-transparent-png-in-ie6
Check the first bit of text under 'The pitfalls' heading
I'm using google chrome 5.0.307.9 beta under ubuntu 9.10 and it seems not properly render css opacity.
Using "opacity: 0.5;" under both windows chrome or windows/linux firefox make my element half transparent, but this attribute seems ignored on linux chrome. This was working on previous versions.
Any ideas about what's going on ?
For sure this is a bug in google chrome itself. using opacity: 0.5 is totally valid CSS markup, and it will work on the windows [and mac?] versions of chrome.
For now, all you can do is... try using a different browser [firefox/safari/konqueror], or ignore that your div isn't partially transparent until the fix comes.
I know that isn't really a solution, but I don't think there is much that you can do =/
Hope that helps.
This was a bug in the build, I noticed problems in a VM a week ago with this, update your chrome to resolve, current release is 5.0.322.2 Fixed it on the VM here at least, hopefully the same for you.
I've got a website that I've just uploaded onto the interwebs, and it's displaying differently using Firefox 3.0.1 on Ubuntu and WinXP.
Two things I've noticed on Ubuntu:
The favicon is missing
The background color isn't displaying (it's set in the stylesheet)
What have I done wrong? The CSS file is being fetched under Ubuntu, so why isn't it applying all of the stylesheet, just the bits it likes? And why isn't the favicon displaying? Are they the same problem?
The answer on the background color: invalid HTML. But I'd love for someone to explain why it works under Windows and not Ubuntu.
The answer on favicon: previously, there was no favicon. The browser cached the lack of favicon. Clear the Firefox cache, and all is well.
I would first suggesting getting you html and css code validated. If there are any errors in your markup, these can cause errors in the rendering.
CSS Validator
HTML Validator
I've also run into differences between FF3 on WinXP and FF3 on OS X (mostly with CSS positioning). The CSS and HTML both validated properly, but I was never able to figure out why there was this difference. I would think that the rendering engine would be the same, but apparently there are at least a few subtle differences.
I agree.. there are subtle differences between the two operating systems. Part of this is just font sizes and how line height and letter spacing is determined. So much of page flow is based on these whitespace elements interact with other page elements.
i believe this is a font issue and a browser / OS issue.
we know that different firefox versions are dependent on the OS - there are some firefox extensions available for Linux, some firefox extensions for windows are available.
it's the font I guess.
Try to download mtts core fonts (microsoft true type ) which includes all the windows fonts so that firefox can display the fonts you specified in the css.
also you could check that you use fonts which are available on both platforms. Otherwise, I suggest rechecking and revalidating your code.
The other issue could be the screen resolution. It might be okay in windows with your high resolution but not with the low resolution ubuntu version.
Almost too obvious to say, but are they both "Firefox 3.01"? One isn't, for instance, Firefox 3.01 revision 3 update 6 service pack 9 and the other, well, you get the picture.
Even if they were both the very latest Firefox for that platform, doesn't mean they're exactly the same thing.
To see what's different, enter about:config in the address bar in Firefox in both Linux and Windows, press Enter, and compare the output
Ubuntu (I believe) apply their own patches to Firefox, so maybe this cause. Having said that, I thought that the patches were only for minor, GUI-type changes.