WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 12 months ago

#22329 new enhancement

Retina Gravatars

Reported by: miqrogroove Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: 2nd-opinion
Focuses: Cc:

Description

Mentioned by Matt in #21019

Should be a simple matter of changing get_avatar() in pluggable.php so that the requested size is twice the display size.

Attachments (3)

miqro-retina-gravatars.diff (1.4 KB) - added by miqrogroove 21 months ago.
HiDPI Gravatars, tested and working!
hidpi-gravatars.zip (2.3 KB) - added by miqrogroove 21 months ago.
Plugin solution involving Javascript to replace avatars after page load.
miqrogroove.com.png (86.4 KB) - added by andy 21 months ago.
screen shot with gravatar

Download all attachments as: .zip

Change History (30)

miqrogroove21 months ago

HiDPI Gravatars, tested and working!

comment:1 alexvorn221 months ago

  • Keywords needs-testing added

I see that your patch just double the avatar size. And,
what is the point having HiDPI gravatars on non-retina devices?

comment:2 alexvorn221 months ago

  • Keywords 2nd-opinion added; needs-testing removed

comment:3 follow-up: miqrogroove21 months ago

Serving HiDPI to all clients avoids the addition of client detection scripts. Since Gravatar doesn't offer a better solution, this seemed like the best way to go for now.

comment:4 in reply to: ↑ 3 alexvorn221 months ago

retina support is made via css file not via php...

comment:5 follow-up: miqrogroove21 months ago

lol okay then show me the CSS for Retina Gravatars :)

comment:6 in reply to: ↑ 5 alexvorn221 months ago

Replying to miqrogroove:

lol okay then show me the CSS for Retina Gravatars :)

I think a new ticket should be added: Twenty Twelve: Gravatar support for retina displays, and there maybe I will show an example. ;)

Last edited 21 months ago by alexvorn2 (previous) (diff)

comment:7 miqrogroove21 months ago

I propose that a second solution would be to generate two IMG elements for every Gravatar, with each non-Retina version having a common class, and each Retina version having both a common class as well as an inline STYLE attribute having display:none. This would be backward compatible with non-Retina themes, and would allow new themes to reset the display properties based on the class names.

The drawback would be the duplication of all of the IMG elements, resulting in a larger response entity.

comment:8 toscho21 months ago

  • Cc info@… added

That would make the site significantly slower without any benefit for 95% of all visitors. That’s plugin territory.

comment:9 miqrogroove21 months ago

Based on feedback in IRC, a Javascript solution may be ideal. I'll put it together in plugin form, and if not implemented I can release it that way.

miqrogroove21 months ago

Plugin solution involving Javascript to replace avatars after page load.

comment:10 miqrogroove21 months ago

Plugin attached. This is the Javascript strategy, resulting in more bandwidth used by Retina devices (they have to load the Gravatars twice), and less bandwidth (just the script) for standard resolution devices.

comment:11 beaulebens21 months ago

This solution makes a lot of assumptions that make it pretty fragile:

  • That s= is the last parameter on the URL
  • That all images with class="avatar" are Gravatars
  • That there are no other parameters ending in s (e.g. &monsters=something)

Unfortunately I think this is significantly more complex to do in a way that covers all variations in a cross-browser fashion. I'll see if I can round up some more details.

comment:12 miqrogroove21 months ago

First assumption is not true. The other two, yes.

comment:13 miqrogroove21 months ago

This will not get a 3.5 milestone according to Nacin in IRC. I'll leave this ticket open for brainstorming, and get the plugin version released.

beaulebens, regarding your third assumption, I should be able to parse on both ?s= and &s= rather than just s=. That would only leave your one concern about avatars that are not gravatars. Perhaps to make the plugin a bit less fragile, I can add an if statement to confirm the presence of the s= parameter before modifying any image attributes.

comment:14 beaulebens21 months ago

Since you already have the src of the image, why not just check for the string 'gravatar.com' in it?

comment:15 miqrogroove21 months ago

I agree. I am adding a check on the domain name as well as the extra hooks for admin pages and the admin bar. :)

comment:16 miqrogroove21 months ago

I've got the above issues ironed out. New plugin files will be at these URLs

http://www.miqrogroove.com/pro/software/
http://wordpress.org/extend/plugins/hidpi-gravatars/

comment:17 alexvorn221 months ago

  • Cc alexvornoffice@… added

comment:18 andy21 months ago

Prior art: http://wordpress.com/wp-content/js/devicepx.js

A version of this script is included in all pages while Jetpack is activated.

It polls the browser zoom level and updates gravatars and other image URLs with known height/width parameters. This has been in operation for several months with no reported issues.

Detecting zoom level is more complex than detecting device pixel ratio. The script actually tries to map the image resolution directly onto device pixels. One of the benefits of this approach is that it also improves visuals on all devices (even LoDPI) when the browser is zoomed in. Try zooming in on any wordpress.com blog with gravatars. For another example, when viewing on an iPhone with 2x pixels, in landscape mode mobile safari will zoom to 1.5x for a logical device pixel ratio of 3x. This devicepx.js detects this and loads the 3x resolution.

You are welcome to integrate any part of this code into your plugin or core patch.

comment:19 follow-up: miqrogroove21 months ago

Don't users expect images to get blurry when zoomed?

When you say the iPhone zooms to 1.5x in landscape, is that automatic? For example, if you went to my website would you be able to find a blurry Gravatar and take a screen shot of it?

comment:20 in reply to: ↑ 19 andy21 months ago

Replying to miqrogroove:

Don't users expect images to get blurry when zoomed?

Yes, in the same way they expect their blender to get stuck with a bubble when making a milkshake. It's the kind of expectation you break if possible. Just as text is re-rendered at the zoomed resolution, images with a hi-res src are re-rendered. All we're doing is upgrading the src when we detect the zoom is > 1. That's a win.

Note that this only operates on image URLs that match the patterns in the script. They either exist on a known image resizing service (gravatar, files.wordpress.com) or they have 1x in the right place in the filename. Other images are left alone. So it's hard to imagine a case where this would be undesirable.

When you say the iPhone zooms to 1.5x in landscape, is that automatic? For example, if you went to my website would you be able to find a blurry Gravatar and take a screen shot of it?

Sure.

comment:21 follow-up: miqrogroove21 months ago

I'm finding this unintuitive because on my website if I don't specify a zoom level 1.0, iPad gives me a pixel ratio of 2.09 in landscape and 1.57 in portrait. So 2x Gravatars work great there. I might just have to get my hands on a friend's iPhone to see what's going on with a 3x ratio.

andy21 months ago

screen shot with gravatar

comment:22 in reply to: ↑ 21 andy21 months ago

Replying to miqrogroove:

I'm finding this unintuitive because on my website if I don't specify a zoom level 1.0, iPad gives me a pixel ratio of 2.09 in landscape and 1.57 in portrait. So 2x Gravatars work great there. I might just have to get my hands on a friend's iPhone to see what's going on with a 3x ratio.

devicepx rounds up so you'd get 2x for 1.56 and 3x for 2.09.

comment:23 miqrogroove21 months ago

devesine on IRC pointed this out http://webdesignerwall.com/tutorials/iphone-safari-viewport-scaling-bug

I switched my site's viewport to device-width, so I have an idea of what's going on with the "3x" issue.

I'm satisfied that the devicePixelRatio and the zoom level are still two separate issues. In other words, loading 2x Gravatars doesn't hurt anything. Whether or not to reload images during zooms would be a design decision.

comment:24 miqrogroove20 months ago

A note on the direction the plugin is taking: The pure Javascript solution doesn't catch Gravatars added by ajax actions. This problem is less obvious in the devicepx.js solution because the script gets executed every second after page load. Still, devicepx.js is not needed. I was able to implement server-side Gravatar filtering by setting a cookie in Javascript on the first visit. This strategy is compatible with admin pages only. Admin pages don't get cached. If anyone is using ajax on the front end, I'll have to figure out how to hook into those hits without affecting the cached pages.

comment:25 miqrogroove19 months ago

I did some research into whether this could be adapted to HiDPI printer output. The closest Javascript facility I found was the matchMedia.addListener() method. In Chrome, this got me as far as actually loading the 2x Gravatars, but the print preview became so unstable that all other output was effectively corrupt. It looks like that side of HiDPI technology isn't ready for use in the wild.

comment:26 johnbillion17 months ago

  • Cc johnbillion added

comment:27 johnbillion12 months ago

#24887 was marked as a duplicate.

Note: See TracTickets for help on using tickets.