Make WordPress Core

Opened 12 years ago

Closed 20 months ago

#21455 closed enhancement (maybelater)

HiDPI (retina) theme custom backgrounds

Reported by: nacin's profile nacin Owned by: joemcgill's profile joemcgill
Milestone: Priority: normal
Severity: normal Version:
Component: Customize Keywords: close
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 (16)

#1 @Otto42
12 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
12 years ago

  • Cc aaroncampbell added

#3 @Otto42
12 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
12 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
12 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
12 years ago

  • Cc j@… added

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


9 years ago

#8 @wonderboymusic
9 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.


8 years ago

#10 @wonderboymusic
8 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.


8 years ago

#12 @joemcgill
8 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.


7 years ago

#14 @westonruter
7 years 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.

#15 follow-up: @celloexpressions
3 years ago

  • Keywords close added

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.

#16 in reply to: ↑ 15 @desrosj
20 months ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.