We Keep Coding

Is there a way I can force chrome to do subpixel rendering for a slow translation?

Im doing a very slow transition of a background image (a view of space that slides slowly to the left). My problem is while it looks beautiful on Firefox, it looks horrible on Chrome. I get a "jittery" effect due to Chrome's lack of subpixel rendering, and the image just snaps to the next pixel. I cannot speed the image up because it will destroy the effect Im trying to achieve. I have tried using TranslateZ() tricks, I have tried every CSS3 effect I could think of to make it look better, Ive tried Kinetic.js, Ive even tried Babylon.js hoping that WebGL would fix my problem.
At this point Im at a loss and I might just have to give Chrome users a static background and cater more to the Firefox users in regards to the neat little things I can do for the UI UX, and then just put a disclaimer on my site saying that the page is best viewed in FF.
I REALLY dont want to do this. Is there ANY work around at all?

You can force subpixel rendering by applying a small transformation:
#container {
transform: rotate(-0.0000000001deg);
-webkit-transform: rotate(-0.0000000001deg);
}
But instead of using JS to make the animation work, why not use CSS3 animations?
If you use transform: translate() browsers will use subpixel-rendering by default.
Also since the performance is better you shouldn't get your jittery/wave motion.
More info on performance here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/
I've put together a simple demo here: http://jsfiddle.net/yrwA9/6/
(For the sake of simplicity I only used the -webkit- vendor prefixes)

Rendering bug in Google Chrome at certain window widths

My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65

(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.

Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.

Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.

Make Jquery UI drag and drop work when zoomed out

I was looking at this drag and drop demo for Jquery UI. The demo works fine at a normal zoom. But if you zoom out to say, 50%, things get wonky. http://www.elated.com/res/File/articles/development/javascript/jquery/drag-and-drop-with-jquery-your-essential-guide/card-game.html
Can anyone suggest a way to fix the demo?

As far as I know, browser zooms and javascript/jQuery don't play nice. A half a decade ago, zooming on the browser didn't zoom images (at least in IE), etc.
http://bugs.jqueryui.com/ticket/4140 Here's an issue suggesting that there's no way to fix zoom-related bugs that arise in jQuery. It's from two years ago, but it says:
Unfortunately it is impossible to my knowledge to reliably detect the page zoom and its value in any browser, so I have to close this ticket for now. If you find a way to detect it that doesn't cause significant overhead, please reopen.
I found that if you're in Google Docs and you use the browser zoom, an message will show alerting the user that different zoom levels are not supported. So I think the best choice for you, if you wanted to fix this, would be to do the same thing that Google is doing.

Is there a way to hide the artifacts that show up in webkit browsers when using jQuery animate?

I am using jQuery animate to slide in items on a web page. For some reason, only in webkit browsers, there is a trail of artifacts across the space the element was animated over. Is there a way to stop this from happening or hide it?
They are seen on the carousel once you load the page here: http://www.mywebclass.org/~jeff/

In your animate callback, scroll down 1px then back up 1px:
$(this).addClass('active');
scrollTo(document.body.scrollLeft, document.body.scrollTop + 1);
scrollTo(document.body.scrollLeft, document.body.scrollTop - 1);

On this machine here, I can't see any trails, but i know the effect you're talking about.
It's not directly a solution, but I seem to remember that animating the left-property is very resource-heavy on slower systems. It would probably lead to an overall more smooth experience if you would work with a <div> where overflow:hidden; is set and one larger slide, that you move by animating scrollLeft() instead of these animations.
There was a post on jQuery for Designers about that, i'll update once i've found it.
Update: "jQuery for Designers - Fun with Overflows"

I only see the leftovers of the animation in the H1 which I think is caused by using a non standard font.
It's not a solution but if you can't prevent it, you can remove those little bastards by just scrolling the webpage 1 pixel up or down.
You're also using an outdated version of jQuery (1.3 instead of 1.6.2), is there a reason for this? If not, you should use the latest version

Trails on the left side of #font-face text animated using the left property in Chrome & Safari. I found that using some padding left on the text and adjusting the animation to accomodate fixed the problem.

Detect Zoom in Firefox

I want to detect if the browser is zoomed in or out (don't really care to know the value, but I assume it will need to be found anyway in the decision process). I have read a lot of other SO posts on the topic, but none of the solutions given work on FF (although there is an IE7/8 and chrome solution).
Oh, and I can't use flash, so the flash solution is out of the question.
Edit: And I must be able to detect this on the initial page load

With modern versions of FireFox, you can now do the following:
DPR = window.devicePixelRatio;
if ( DPR <= 0.999 || DPR >= 1.001 ){
// User has zoomed in or zoomed out
}

If by zoom you mean that the user pressed ctrl/cmd+[plus] and not css transformation you can detect computed font-size. Just checked in FF 4.0.1/Mac and it worked for me. To detect computed font-size I used code from this question: Get computed font size for DOM element in JS .
The value changed after zooming. You need to know what the font-size of a certain element should be (as set in css) and compare it with what it really is.

I suggest you look at this generic question. And possibly close your own as a duplicate (not voting to do this myself, since it's not "an exact dup".

Did you try to detect the resolution, which may help you to detect the zoom.

Maybe instead of detecting the zoom you could detect the error.
For example if your layout expects an elements' offset to be at 100,200 and a query shows it's at 300,450 you'll know it's in the wrong place and you can apply your fixup/workaround.
This has the added benefit that if the zoom issue is fixed in a future version of the browser you won't be applying your fix needlessly or incorrectly.