WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#24024 closed defect (bug) (wontfix)

Twenty Thirteen: Consider Header Image Sizing for HiDPI, non-HiDPI, Mobile, and IE8 Compatibility

Reported by: celloexpressions Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Currently, all of the built-in header images are sent at 3200px wide to all browsers regardless of HiDPI or viewport, and sized down to 1600px with background-size.

For non-HiDPI displays, there's no reason to go over 1600px wide, so the images should be shrunk to save on bandwidth (though they're quite small already). Load the smaller images by default and add the media queries to pull the larger ones on HiDPI devices (already being done for search icon and dotted-line images, not a big deal to do in custom-header.php as well).

It's also worth considering even smaller images for mobile devices, but that could be somewhat messy to do in addition to HiDPI for those devices.

IE8 doesn't support the background-size property, so the header image displays at full, 3200px size (see screenshot). The built-in Twenty Thirteen header images aren't designed to be size/position-dependent, but perhaps this is too visually different? Using 1600px by default would resolve this (this is what led me to notice all of these issues).

Custom headers, on the other hand, are only created for frontend at the 1600px width, so they will display normally in IE 8 but not optimally for HiDPI. I would suggest making multiple sizes for display at different resolutions of the images users upload, as would be done for built-in images. I doubt 3200px images will be uploaded frequently, but they might at least be more than 1600, and background-size will adjust accordingly if the images are between 1600 and 3200 px wide. Looking at custom-header.php, this may not be as easy as it seems due to the reliance on core functions for the custom header and the lack of support there. But it should be trivial with core's image resizing capabilities.

Attachments (1)

twenty-thirteen-bigheader-ie8.png (47.4 KB) - added by celloexpressions 12 months ago.
IE8 Header Display (3200px image doesn't size down)

Download all attachments as: .zip

Change History (9)

celloexpressions12 months ago

IE8 Header Display (3200px image doesn't size down)

comment:1 obenland12 months ago

Lance, Joen, and I talked about this issue during early development of Twenty Thirteen. We decided to go this route because there really is no easy way to determine whether the current header image is retina-capable or not. That is different with the other images you mentioned, because they don't change.

As you pointed out, the bundled header images are really small (between 14kb and 33kb, the theme's screenshot.php is 81kb) and all custom header images will be 1600x230px anyway. So the only hiccup we're actually looking at is a "zoomed" header in IE8. And even that only when it's a default header image. It does not impede site navigation or break the header.

I can't thank you enough for testing Twenty Thirteen in IE! I'd vote wontfix for this particular issue though.

comment:2 celloexpressions12 months ago

No problem! I think all of the bundled headers look fine at the large size, so unless there's an easy fix for IE8 background size it's probably fine as is (that is the only functional problem).

The only other related issue I see is potentially large (filesize) header images that users upload that could waste bandwidth on mobile devices (loading 1600px image that you see 400px of horizontally). It should be easy to create additional versions of the cropped thumbnail that crop down further horizontally and are used at progressive breakpoints. Well, I know how I'd do that with a custom implementation (using WP_Image_Editor::resize()), I'm not sure with the way Twenty Thirteen does it with the core custom header features. And I may be totally missing something here.

Also, it seems strange to only use the retina image for the default header (assuming that a solid percentage of users will stick with it as they have in previous default themes from my observations) but to use separate 2x images for dotted-line.png (6 byte difference) and search-icon.png (~400 vs. 800). Remembering to change/override these if needed in child themes is slightly annoying and easy to miss, so there is some reason not to bother, but that's an edge case of course. When the files are that small, does it really make much of a difference to do the non-retinas separately? That would probably break those for IE8 though, more problematically than for the header...

comment:3 obenland12 months ago

  • Keywords close added

What you are suggesting goes way beyond the scope of a theme and this ticket. Serving different header image sizes would be something core would have to tackle. Also, on top of header images, content images would be to worry about here too. If you have thought of a way to accomplish this, feel free to open a ticket with your proposed solution!

Again, we can make the differentiation here because the dotted-line and search-icon images won't change. Also, a double-sized search icon in IE8 would break the search form, while the header image does not.

comment:5 lancewillett12 months ago

+1 to wontfix, but great discussion.

Also, in general it's not a great use of time and energy to spend time optimizing for IE8—it's destined to continue dropping quickly in usage over the next few months.

comment:6 follow-up: celloexpressions12 months ago

I also agree with the wontfix, and now at least we have a record of the header decisions. I'm not familiar with the core custom header functions, but I'll look into to them more and see if multiple sizes could fit in there, along with the retina support.

On the IE note, will Twenty Thirteen or other bundled themes ever reject or notify users of outdated browsers on the frontend, or will it just not work well for them? That sort of dictates how far you can go, I gave up on IE<9 a while ago.

comment:7 in reply to: ↑ 6 ; follow-up: obenland12 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to celloexpressions:

I also agree with the wontfix, and now at least we have a record of the header decisions.

Very true, thanks for bringing it up!


On the IE note, will Twenty Thirteen or other bundled themes ever reject or notify users of outdated browsers on the frontend, or will it just not work well for them?

No they won't. The only thing that comes close to that is the browser nag on the admin dashboard.

comment:8 in reply to: ↑ 7 celloexpressions12 months ago

Replying to obenland:

On the IE note, will Twenty Thirteen or other bundled themes ever reject or notify users of outdated browsers on the frontend, or will it just not work well for them?

No they won't. The only thing that comes close to that is the browser nag on the admin dashboard.

I have a plugin that does that for frontend (Browser Rejector), so just wanted to check.

Note: See TracTickets for help on using tickets.