HiDPI (retina) theme custom backgrounds

[nacin]

We should support HiDPI custom backgrounds.

This will be a bit easier than custom headers, #21389, as we can do a media query in _custom_background_cb(). Worth noting that we will still need to solve some aspect of retina uploads, #21038.

[Otto42]

Problem: Backgrounds don't have "sizes". So the question is when to use a different sized background.

Options:

• Provide a separate image uploader or choice for hi-dpi background entirely. (hat-tip Aaron Campbell)

• Allow the user to check a box or something, which causes WP to generate a half-width image of the background, and use that for the normal case while using the full size background for the hi-dpi case

Both are easily doable, but there's no doing this completely transparently because backgrounds just don't have a "size" inherent in them at the moment.

[Otto42]

After banging my head on a wall for 3 weeks on this one, I'm inclined to say push it to 3.6 or "wontfix" it.

Basic problem as I stated before: backgrounds don't have any indication as to widths.

Two cases to consider:

• BIG background images have an inherent problem in that we don't know what the intended width of the background image is supposed to be. So if the image is large, do we half-size it and use the uploaded version as the HiDPI version?

• SMALL background images have an inherent problem in that scaling small images down looks terrible. If you take a 32px tiled image as the HiDPI version, and scale it down to 16px for the normal case, it looks just awful. Every site that has HiDPI tiled backgrounds includes two separately made versions of them at each size (ask koop to show you some example sites with HiDPI tiled images). So you kinda need a second uploader.

I have no solution to this problem. Everything I've tried short of adding an entirely separate image uploader box has a major downside.

Suggestions welcome.

[nacin]

I think supporting user-uploaded HiDPI images in core for 3.5 is not going to be feasible — backgrounds and then some. Agreed on the punt. Let's see what happens with media in 3.5 and see what we can then do in a plugin.

[nacin]

​The IRC meetup yesterday confirmed that HiDPI support for user-uploaded images is no longer part of 3.5's scope, due to the complexities of implementation. With the media UIs and image APIs improving quite a bit in this release, it ideally becomes more feasible in a future version. It is unfortunately too much at once to try it in 3.5 while everything it would be built upon is also shifting around.

Combined with the fact that HiDPI support everywhere on the internet remains a total hack, this also gives browser makers and standards bodies some more time to come up with a sane way to handle HiDPI support.

Otto42 will be watching #21390 (and related tickets) closely to make sure the right hooks are in place so this can be attempted in a plugin.

This applies to #21038 (user content), #21455 (backgrounds), #21389 (headers).

[wonderboymusic]

Let's see what we can do here

[wonderboymusic]

We can let this ride while deciding a final outcome

[joemcgill]

Since background images are implemented in CSS instead of through an <img> element, we aren't going to get any benefit from the new responsive image markup implemented in browsers. That said we're left with exactly the same issues @Otto42 described three years ago.

However, I would suggest that we look at this from the opposite direction. We should only load the full size image in the background if the viewport is large enough to need it. In cases where the viewport is smaller, we should load one of the smaller intermediate sizes. Still, we'll need to know the width of the background image in order to do the calculations. Currently we only return the path in get_background_image().

At any rate, too late for 4.4 so I'm going to punt for now.

[westonruter]

If core is to add support for this, I think a solution could be to add a high-dpi feature flag to the custom-background theme support. For example:

<?php
add_theme_support( 'custom-background', array(
        'default-color' => '#0000',
        'high-dpi' => true,
) );

When that is present, core could automatically add background-size: 50% or however high-dpi background images are indicated. Otherwise, themes can do this themselves. Maybe I'm being overly simplistic. In any case, it has to be an opt-in thing.

[celloexpressions]

WordPress 4.7 added user-facing controls for background-size, background-position, and background-attachment in the customizer. It's possible to upload a high-resolution image and scale it down accordingly with that system (although there's a limitation on maximum size with uploads auto-scaling to 2560px widths now).

Regardless, blocks are set to replace the specific implementation of custom backgrounds moving forward with block-based themes. So I recommend closing this as either (retroactively) fixed in 4.7 or wontfix.

[desrosj]

Replying to celloexpressions:

Regardless, blocks are set to replace the specific implementation of custom backgrounds moving forward with block-based themes. So I recommend closing this as either (retroactively) fixed in 4.7 or wontfix.

Now that blocks are here along with full-site editing, I'm going to close this one out as a maybe later.