WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 10 months ago

#21455 assigned enhancement

HiDPI (retina) theme custom backgrounds

Reported by: nacin Owned by: joemcgill
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Customize Keywords:
Focuses: Cc:

Description

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.

Change History (14)

#1 @Otto42
5 years ago

  • Owner set to Otto42
  • Status changed from new to assigned

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.

#2 @aaroncampbell
5 years ago

  • Cc aaroncampbell added

#3 @Otto42
5 years ago

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.

#4 @nacin
5 years ago

  • Milestone changed from 3.5 to Future Release
  • Type changed from task (blessed) to feature request

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.

#5 @nacin
5 years ago

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).

#6 @betzster
5 years ago

  • Cc j@… added

This ticket was mentioned in Slack in #feature-respimg by nacin. View the logs.


3 years ago

#8 @wonderboymusic
2 years ago

  • Keywords responsive-images added
  • Milestone changed from Future Release to 4.4
  • Owner changed from Otto42 to joemcgill

Let's see what we can do here

This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.


2 years ago

#10 @wonderboymusic
2 years ago

  • Type changed from feature request to task (blessed)

We can let this ride while deciding a final outcome

This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.


2 years ago

#12 @joemcgill
2 years ago

  • Keywords responsive-images removed
  • Milestone changed from 4.4 to Future Release
  • Type changed from task (blessed) to enhancement

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


10 months ago

#14 @westonruter
10 months ago

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.

Note: See TracTickets for help on using tickets.