Comments

It's not an "effect" or something "strange". The image is just stretched vertically, that's why it becomes blurry. There must be some rule that causes that, either in your custom style or a leftover from the original site rules.

This is a Firefox bug/feature. With your changes, the image shifts down about 1/4 pixel on hover. If that's far enough to convince the browser to move the image lower [1], Chrome simply redraws the same image 1 pixel lower, while Firefox tries to render it a fraction of a pixel lower by means of an SVG transform (or some other subpixel rendering magic).

In Chrome the affected images simply move down one pixel on hover. In Firefox each display pixel becomes a composite of the neighboring pixels in the unshifted, pixel-aligned image, which (1) blurs the shifted image and (2) renders it 1px taller because the image that was N+fraction display pixels high and thus contributed to N+1 rendered pixels is now fraction+N+fraction display pixels high and contributes to N+2 rendered pixels. [2]

Remember that margin-height: 22% is 22% of the container width, not height; if you want to use relative units here, em is a better choice. It may be easier to absolutely position .over-nav within .photo.

[1] Specifically, if the top half of the pixels in the next display row are covered by the bottom edge of the repositioned image, Chrome will move the image and Firefox will redisplay it.

[2] Well, almost. The details depend on how browsers make page reflow finish quickly. When the browser reflows (part of) a page it starts in the upper-left corner and works from top to bottom and from left to right looking for layout changes. Suppose a 332w x 500h image was originally resized to 197.5w x 297.44h and rendered as 198w x 297h, and now it has moved down by 0.3px, which triggers a reflow.

When Chrome reaches the image, it sees that the top edge has moved from something.0px to something.3px, rounds the value to the nearest pixel, and decides that, for the purpose of reflow, the image hasn't moved. It then sees that the bottom edge has moved from something.44px to something.74px, rounds to the nearest pixel, and decides to move the rendered image. It wants to finish quickly, so it simply copies each rendered row of pixels to the following row of the new bitmap. Every pixel of the image is displayed 1px lower in the new rendered bitmap.

When Firefox reaches the image, it too sees that the top edge of the resized image is now 0.3px below the top edge of the display row, but it wants to be more clever than Chrome, so it leaves 70% of the pixel intensity in the same display row and adds 30% of the intensity to the following row of the new bitmap. This way the visual "center" of the pixel moves 0.3px down instead of jumping by a full pixel as in Chrome, and Firefox can do it row by row so it's just as quick as Chrome at reflow. Now though each original row of pixels bleeds a little into the next row, and some of the last rendered row of the original image bleeds into the row that follows it so the image appears 1px taller than it was.

Basically, when you make a small change to the layout, such as the :hover change in your style, a browser will use a shortcut if it can to avoid recalculating the layout for the entire page. Usually the shortcut is good enough, but sometimes there is artifact.