I think adding this to customizer is a good idea. I tested background-position: left bottom; and it works in Chromium 20 and Firefox 15. We may need to check if IE8 would support the vertical position.

@grapplerurlrich the patch works if you set horizontal then the vertical but if you go back to change the horizontal after setting vertical it sets vertical to top. At least in the preview, it does save them correctly and display as expected on the site.

@grapplerurlrich the patch works if you set horizontal then the vertical but if you go back to change the horizontal after setting vertical it sets vertical to top. At least in the preview, it does save them correctly and display as expected on the site.

@MikeHansenMe Thanks, I updated the patch. I also saw a problem with the "background-attachment:" and fixed that too. How long will it take for it to be implemented in WordPress?

Tested and can confirm the customizer is now working as expected. We are currently in a feature freeze for this release cycle so it will likely be reviewed after 3.5 comes out when enhancements are being considered. Thanks for contributing.

When you change the vertical positioning of the background image the preview does not update. It does after saving and refreshing. However, it should happen like horizontal does with immediate preview before saving. I tested using FF 20 and Chrome 25 on Ubuntu. I can test on Windows tonight to see if it works on Windows w/ IE.

When you change the vertical positioning of the background image the preview does not update. It does after saving and refreshing.

Are you sure you're testing the latest patch? Please revert any changes and then apply attachment:22058.diff​. Just tested it on IE and it seems to behave correctly. Where exactly do you encounter the issue, in Theme Customizer, in Appearance > Background or both? What are the steps to repoduce it? Thanks for helping.

Well, that's really strange. Just tested it again, now using IE9 and FF21 on Windows and it works as expected. Please check that you have defined SCRIPT_DEBUG in your wp-config.php file:

define('WP_DEBUG', true);
define('SCRIPT_DEBUG', true);

It seems that everything is loaded, except recent changes to JS. Maybe you're using the minified scripts which are not affected by the patch. If it's not this, please take a look at the console and let me know if there are any errors. Thanks!

Current patch still applies but I'm not really satisfied with the growing list of radio buttons. I've attached two concepts illustrating variations of the idea that could improve the interface and usability.

I really like the idea of an alternative UI to the radio buttons - the position concept in particular is very compelling. The others seem a little harder to understand as plain icons when you're not versed in CSS - even the words are tricky. For instance, attachment seems like it could be a checkbox, for instance, and called "Scroll with page" or something.

22058.1.diff​ builds on all of the previous work here to introduce an almost-entirely-reworked UI for custom backgrounds in the customizer.

Text radio buttons are replaced with visual representations of each option, background positions can be set vertically and horizontally, background-size can be set (merged from #26386), tiling is depicted visually, and background attachment is represented with a "scroll imge with page" checkbox.

This should all be backwards compatible, although the background attachment checkbox could use a bit more work. I kept the existing work on the old backgrounds admin page in the patch, but didn't add background-size there since that page is only shown to no-JS and IE7 users by default, and isn't really maintained or supported by most themes at this point.

The UI could use refinement - feels fairly heavy to me, which could probably be resolved with color, but I want to ensure that there are nice big tap-targets, consistency with the use of a single icon when representing each of the options visually, and using white backgrounds on the buttons to indicate clickability. The buttons-as-tiles follows a similar UI to the media modal, with the use of thick borders to indicate selection and hover. Definitely want to avoid making these look like the core "buttons" style, because there are so many of them and that would add a lot of visual clutter (with rounded borders, shadows, etc). The hope is for them to read as images representing each choice. See the screenshots and gif above for the visual. Because traditional radio inputs can't be used here, I went with <button>s for each choice, with screen reader text representing each option with the hope that this can be similarly accessible.

In the background, there's one new customizer control to handle all of the image-select controls. This could potentially be used outside of core for other things, but it requires quite a bit of CSS specific to each use and one of the background options needs to handle two settings assigned to one control, so it's name is specific to backgrounds for now. It would be cool to build something like a layout control that uses a similar UI in core for themes and plugins to extend in the future, but let's focus on this one control for now.

It's been a long time since custom background has gotten much attention, so let's polish this up in the next few weeks so it's ready early for 4.7.

I find this a bit complex. It would certainly put me off using the function or recommending it to clients. [cdog's version from 17 months ago] is a bit better but the functionality is fairly obscure. The results look a little MySpacey. Are there people using these background functions and are they using the edge cases? While the current flexibility is amazing, it would be far clearer to have just three simple, attractive and usable presets available in the standard interface.

22058.2.diff​ tweaks the colors to match the text color (#555) for the icons and use the darker gray for the selected border, and this feels better to me. It also fixes a bug on screens between 400-600px wide with the background position control.

@afercia: is the use of <button>s with screen reader text contents for each choice an appropriate way to handle accessibility? I tested on keyboard and it works well there, not sure about screen readers though.

@FolioVision: while I'd prefer not to have these options at all, this is how the custom background functionality works. If it were being built today, I doubt we'd have user-facing options for anything other than the image. But given that this feature was originally introduced 5+ years ago, we need to work with the assumptions that it makes. I don't know that we could determine three reasonable pre-set combinations that would be appropriate in the context of a given theme or image, let alone for core in general. I would also guess that a majority of themes no longer use this feature and a majority of users don't mess with the options, perhaps beyond setting an image.

It's really hard to make many assumptions about what a user might want to do with these options besides the fixed/cover-sized approach that's probably the most common right now. We know that background-repeat doesn't apply when background-size is cover, but beyond that we can't really hide any options based on other settings. A lot depends on the size and aspect ratio of the selected image and the size and orientation of the end user's screen. My goals here are to make the options more visual, reducing the use of technical terminology, and to fill in the clear gaps in functionality while prioritizing the most important options and providing a more appropriate flow between options. That improves the experience for the users that do use this feature while maintaining full backwards compatibility.

Point well made about not removing functionality, Nick. I played around with the existing background image interface today, and was pretty happy with how simple and smooth the action is. The only functionality which seems missing is the option to compress a large image to fit within the background of a smaller mobile device (although with hires mobile style screens becoming more common, this issue could solve itself: Retina type screens could just use the desktop settings on a per pixel basis which effectively is hires).

There is an argument to be made for making the options visible (but greyed out) before someone uploads an image. It took me a few minutes to understand why there are no options just an upload button. The counter argument is that the additional options even greyed out creates additional mental strain for a normal user analysing information presented about an unused feature. I can see both sides here.

If we agree that background image is not best practices to build a website these days, it seems counter productive to add a whole lot more edge case options - additional options suggests to me that we encourage people to use this tool and those options.

The long run danger I'm worry about would be to make customizer unwieldy, rather than making customizer a cheap and cheerful way to customize a standard theme. The best version of Microsoft Word, it is said, is version 5.1 for Macintosh, released in 1992. There were enough features, elegantly put together to allow a user to learn the program quickly and intuitively and produce very high calibre documents. Almost everything added since have been excuses to force an upgrade. As we aren't selling WordPress (free), in theory we should be exempt from features for features sake.

Background size is really the only new option here, which as you mention is necessary for most cases. The vertical position (which this ticket was originally for, see comments from 3-4 years ago) is more complementing the existing position option and integrates into the same control choice. I think maintining the existing hidden behavior is a good way to keep this UI from making the customizer feel cluttered, as you'll never see it unless you upload an image, and if it looks good after setting the first option (size) or two, you probably won't even look at the more complex things like position.

I will leave more in-depth design considerations to the UI/design team, just wanted to say that I feel this would add a bit too clutter to the UI maybe for little benefit. Comparing the current UI and the proposed one side by side, the latter gives me the impression of a wall of at-first-sight-pretty-obscure icons vs the simplicity of the former:

About accessibility and semantics, radio buttons would be the best option because that's what they are meant for: a single choice between related options. By the way, they would need to be grouped in a fieldset with a legend. About the importance of fieldsets and legends I'd recommend this post by Leonie Watson, goes directly to the point with simple examples: ​https://accessibility.blog.gov.uk/2016/07/22/using-the-fieldset-and-legend-elements/

Worth mentioning there are various CSS techniques to hide the radio buttons and use their label elements to provide a different visual, I think Press This uses one of them.

Please consider every time there's the intent of changing and transforming native controls, then there's the need to replicate all their native functionalities otherwise the native level of accessibility will be decreased. I understand the point to make the options more visual, reducing the use of technical terminology but this shouldn't happen at the cost of reduced accessibility. My general recommendation would be to keep the current radio buttons and just improve the labels wording.

selected state: if radio buttons, that's natively announced by assistive technologies but if <buttons> then they would need an aria-pressed attribute, as done for the "device preview" buttons

initial state (edit: I meant initial default value): not clear why some properties have a clear indication of the initial value and others don't, see also the false value set for these properties in the screenshot below

technical terminology: completely agree to avoid it, I'd also add that some terms are difficult to translate, for example "tile" and maybe the wording should just explain users what a control does with the simplest possible wording

The proposed UI is really heavy and hard to understand. It's honestly super overwhelming. The repetition of the image icon and overall lack of hierarchy makes it super confusing to parse. It's hard to figure out what to look at first when it's just the same thing over and over again.

Firstly, I think a lot of the issues with this solution come from not creating one from observing and testing real users. Note I say real because we are all not normal in our use and creating any solution just because we think it's a good idea without observing, testing and then creating from that point, it isn't a good idea. If we identify a possible issue, we should gather data, observe and then come up with a solution. Not cobble together a best intention. I don't doubt that what has been created is meant to be that and has great intentions at its heart. Unfortunately, it falls short of usability.

What we seem to have after a lot of input and various voices is something very over-engineered for the solution. Something this complex we should always stop carrying on the complexity and consider where we went wrong. I'd say the wrong point here is not actually creating after observing or looking for designer input earlier. That later may have just been a case of us not having enough to spread to Customizer, we're are all try and fix that though and slowly have a better team.

This all said, user testing and actually finding out what does and doesn't work for users isn't something only designers can do. I at no point unless mistaken see this happening for this enhancement. This has got over time more and more complex and more and more iterations without ever having user tested. That's something we should stop as a behaviour. I know we don't always have the people around, but this really is important. I'm happy to help anyone find out how they can do user testing - it shouldn't be down to just a few people or just designers.

This UI to me is a classic example of a paradox of choice, your eyes can't settle and no clear path is obvious. That's bad and not going to ensure it works. I actually beyond that have a lot of issues with even knowing where the positions are in these images. I do not feel this at all is the right path.

I don't think the intention of this ticket is bad and I actually think with some research we could come up with a solid solution. I do not feel the current one on table is that. @melchoyce shows how .com does it and I think that's worth adding as a simpler but just as effective solution. Do we have to do that? No. But, lets actually pause and find the point we escalated without user testing and iterating through a user focused design process.

I am commenting late in this tickets life and I know that can be horrible to do. I don't meant to drive by comment, but we are trying as said earlier to give the attention Customizer tickets deserve from the design team. Please drop tickets like this into the design weekly chat - I'm fairly sure I can speak for everyone that comes to that chat and say we'd love that and promise to take action. I'm also going to spend a few hours tomorrow and look over any flagged for Customizer UI or UX, hopefully we can ensure we don't have to come in late on other features, but we can work together.

Thanks for showing us the .com interface for this feature, Mel. It's considerably lighter. Still I'm not certain it's better than the bare bones text version we have now, apart from the handy colour picker.

How do other people feel? Is the .com version or the text version better for you?

I will note that the proposal I posted above was based on a problem identified by observing inexperienced users, via my work at the ​USC Annenberg Digital Lounge, and the proposed UI is inspired by other projects we've completed in that context for these very non-technical users.

However, based on the discussion above, there are a lot of problems with moving toward a more visual interface. WordPress.com uses icons now, but they present the same challenges as the version I posted, with graphical representations that may or may not be clearer for users, and resulting accessibility challenges (regardless of the actual markup used). We could also nitpick the exact UI - there are other dashicons that would perhaps work better, and I would be concerned about touch accessibility - but despite being considerably different visually, the UI structure is the same and has the same problems. Namely, the functionality is ambiguous but not necessarily worse than the current technical text labels.

Taking a step back, my goal for this ticket is to find a more usable balance between the background property options and an ideal user experience. After some thought, I'm increasingly thinking that the theme should be responsible for all background properties, with only the image being customizable through UI in the customizer. In the rare cases that something else is needed, it can be accomplished with custom CSS via #35395.

Rather than forcing users to decide, theme should set default background-position, background-size, background-repeat, and background-attachment values in their CSS based on the intended use of backgrounds in the theme. If a theme is designed for a tiled texture background, it probably wouldn't make sense for a user to replace this with a full-screen fixed photograph, and vice-versa. This approach would also improve the way custom backgrounds are used with respect to themes, and but the decisions back on theme designers, where they should be. Right now, many themes seem to add custom background support for the sake of it, without considering whether a custom background will look good with the rest of the theme design.

As @FolioVision and I discussed earlier in this ticket, the path to removing these options may be difficult, but if we really want to we could try to make it happen.

Note that background size is new and repeat omits vertical and horizontal repeat - they are certainly used sometimes, but even in my experience as a developer, very infrequently for general body backgrounds. It could also be called "Tile", perhaps, but I find that a little less descriptive when standing alone.

I also like the presets in 22058-presets.png​ but I have a feeling it would be extremely contentious to further reduce options like that and may not be worth it. For reference though, it's rather like what you find in OS background options:

I also like the presets in 22058-presets.png​ but I have a feeling it would be extremely contentious to further reduce options like that and may not be worth it. For reference though, it's rather like what you find in OS background options:

What about something very simple for position like 9 circular radio style buttons (like a tick tack toe grid) for position? In term of the Fill, Fit and Stretch options, perhaps its better to leave them text as in your visual example.

Here's an example of the simplicity of that kind of a grid.

And here's what it would look like in context (current design referenced by @celloexpressions and @afercia above).

I like the simplicity of the nine radio dots, but I'm not sure whether or not users could understand what it means. It could work, but should definitely have at least one inexperienced user test it.

I like the five (ordered) options outlined in comment:44. However, I think that repeat/tile should be off by default. In my testing, I noticed significant performance issue with certain combinations of properties (I think particularly relative to background size and with larger images, in Chrome) when repeat was on, so it would probably be safer to have that off until specifically desired. We can also hide that option when background size is cover.

I can work on a revised patch and screenshots to reflect that late next week, unless someone beats me to it.

Ladies and gentlemen: we're happy to help with the CSS code for the 9 point position picker (or other issues) as soon as the final requirements settle.

@Helen, taking my visual from comment 45 what other additions need to be made? What order would you like the properties in? I know you covered this material once comment 44 but before doing a final mockup, I'd like to confirm your thoughts on repeat (which as celloexpressions notes can cause huge performance issues).

To be honest, I think we know what combinations can kill a site loading and we should show errors (even permanently inline on this dialogue box) warning that that the users choices will make for a very slow loading website. If it were entirely up to me, I'd make it impossible to make those choices at all in the GUI customizer. The internet would be a faster place if anyone who wants to bork their site must learn to code by hand!

I am a little concerned using something so well known as a radio button UI for something like this. It's taking something that whilst in the 9 grid isn't a radio, well it is still. That brings a lot of user confusion potentially. I would caution this as an approach. In saying that, if someone can show me user tests or is interested, we may have fears proven or laid to rest.

@karmatosed Thanks for sharing your concerns. The simple array of nine is so much clearer than anything else on the table, perhaps we should move ahead with the improvement so this ticket doesn't languish in another four years of Trac limbo (really it's been four years).For me the button by default showing in the middle suggests position. Tic tac toe has been around longer than radio buttons.

That said, for differentiation, the round radio buttons could be turned square or the existing round ones could be put in a square box to suggest a page. Anything more and we risk building an ugly interface. Thoughts on square buttons or a square around the nine buttons?

I'd love to help finish this up but that means decisions on all sides.

My post above posed some questions about performance which really worry me. Does anybody have any thoughts on offering users performance warnings here?

I don't agree we should rush in without user testing. Sometimes tickets take a while and perhaps what seems clearer to use isn't. For what it's worth, I don't see the 9 as the better solution, as I've said. I am however keen we get user feedback on this.

Summarizing the discussion in the design chat, it sounds like we don't need to add the vertical-position options due to lack of need/support requests for them (or background-related options in general). We did decided to go with the approach from @cdog if we do add those though. Therefore, we need an updated patch that implements 43.

We also decided to explore an alternate approach that removes these options in favor of a preset-selector (as has been suggested before), which would internally set the values of the existing options for backwards compatibility. We'll need mockups and a patch for that approach as well.

They don't require a preview image anymore as background options are now available inside the customizer only (the wording itself is self-explanatory and you also get a live preview for your choices). I've moved them to a dropdown menu.

Selecting a preset would change the options below based on your selection. Tweaking the options would select the Custom preset automatically.

The background position component may seem a bit too big. I've enlarged the buttons to make them easier to tap on touch devices as they don't have any spacing between them.

This could be achieved using existing dashicons and without creating any new assets. Next, I'll provide a working patch for a potential user test. What do you think? Any feedback is much appreciated.

I like it. There's a bit more 3D shadow in the background position 9 point graphic than currently customary but otherwise it's nice and simple and doesn't encourage performance killing choices (although on second thought some of them are available). Perhaps we should shorten the list of background presets.

A side by side comparision (22058-compare.png​) between the current UI and the proposed one.

Here I also added back the options for background repeat:

No Repeat

Repeat Horizontally

Repeat Vetically

Both

I'm not yet convinced if this should be limited to repeat/no repeat only. See 22058-background-patterns.png​ for some common repeat patterns. While the second scenario may not be used as much today (fixed-width content with vertically repeated background), the first one may still apply in many cases (top aligned horizontally repeated background).

This could be further improved by adding predefined presets which set the background options automatically and toggle the visibility of controls based on user choices. Looking forward for some input. Thanks!

Some clarifications on how presets would work with the actual patch. Here's what I'm thinking:

The preset slector should be the first item, above all other options;

Choosing a preset would change the options below automatically;

Manually editing any options would change the preset to Custom.

Ideally a user workflow would be to upload a background image and choose a preset, then Save. Rest of the controls would be useful for further tweaking the background settings (if needed at all) or if there isn't any preset matching the user's preferences.

I've uploaded a screenshot of Customize > Colors (22058-color-presets.png​) to make an analogy. A user may use a color scheme as it is, customize it, or select each color option to create something new (in this order, I think).

22058.3.png​ is a screenshot of the patch (22058.3.diff​) as it is now. The presets have to be added and for this it would be great a review for what has been done so far.

Great work here @cdog, I reviewed the patch and didn't see any major issues. A couple of suggested changes:

Require and register the position control at the top of each corresponding block of customize controls, since it's most closely related to the base control (and we shouldn't separate the site icon control from the cropped image control that it extends).

Omit the settings parameter when adding the background_repeat control, since the setting id matches the control id and will be set automatically.

It looks like the new file for the background position control was missed in the patch; could you try remaking the patch file to include that? Everyone testing will get a fatal error without that.

@cdog, these new mockups look great. I think the idea of a compact 9 square position selector is nice and simple.

However, I'm concerned about the arrows going out from the center. I showed it to a few non-technical users and several thought that it was controlling the stretching/sizing of the background, despite the labels.

@celloexpressions: I've refreshed the patch and added the missing file, see 22058.4.diff​. It seems that you put some effort into your patch/mockups too so thanks for letting me take the "lead", what you do is really helpful :)

@Kelderic: Maybe changing the wording from "Position" to "Alignment" would help? Or trying out alternate icons? Here's the Align extended toolbar from Open Office. Photoshop/Illustrator does use similar icons for object alignment. Altough I find arrows easier to understand.

Can I suggest that the Background Scroll default to scroll? And/or warn users that fixed background images don't work as expected on mobile devices using viewports?
It's a bit confusing to me to see the screen icons at the bottom of the customizer. Do these settings apply only to the type of screen currently selected? So I have to set it 3 times? or something like that? If so, maybe a different default for the mobile view.

The screen icons at the bottom adjust the live preview viewport size and are hidden on small screen sizes. They are part of the customizer being present on all sections, not only background image. If you have some concerns about their functionality please fill in a separate ticket, I find it broader than the current topic.

@cdog can you update the patch to remove the vertical position options and instead show a 3-button group with left, center and right? We should also use the image-align icons used in the editor. If you could also add the proposed presets that would be great.

I'll try to help make sure this makes 4.7, I think we're really close.

@celloexpressions Any reasons not to keep the vertical position options? The ​background-position property was defined in ​CSS Level 1 and is fully supported even by legacy browsers like older versions of IE. Removing it was suggested before, although this is how the ticket started. Can someone elaborate on this?

@melchoyce, @jorbin I completely agree with you. How to simplify, do you have any suggestions?

22058-variations.png​ shows three variations based on the feedback received so far. Can we pick one of them to go with the patch or there is room for more improvements? Personally I'd stick with option 3. @helen what's your opinion on this?

22058-options.png​ shows a possible implementation (similar with the Menus section from Customizer) of how we can toggle the background options visibility. This should work with any of the above variations. Hiding all options would leave visible only the image and presets.

Looking pretty good @cdog. I think we should call the new control WP_Customize_Background_Position_Control, as it isn't quite a generic positioning control, but could still be useful in themes and plugins. Can we avoid the repetition in there? Maybe loop through a keyed array of values => labels for the nine elements?

The multi-select control isn't keyboard-accessible currently. I think adding tabindex="0" to the input element, and then providing a visual focus style for each radio input styles as a grouped button there that matches the hover style would probably be best. @afercia can you advise whether the implementation in the patch works otherwise for accessibility?

The "dot" you see in the VoiceOver panel is announced as "bullet". I think it's the icon, so I'd suggest to use aria-hidden="true" on the span that holds the icon.

A nice improvement, if possible, would be wrapping the 9 input radio buttons inside a <fieldset> element with a <legend>. Basically the text "Image Position" should be the legend text. Not sure if it can be done right now or if it's more tied to the Customizer controls. Alternatively, a legend hidden with screen-reader-text could work. Worth noting the text "Image Position" is just currently inside a <span> so the semantics could be improved a bit.

@cdog looks good to me. Minor detail, out of curiosity why the CSS class ui-helper-hidden-accessible? Seems to me it's the same as screen-reader-text and if jQuery UI is used, it should be overridden by the core one anyways.

@afercia ui-helper-hidden-accessible is an alias of screen-reader-text. See: wp-admin/css/common.css. We can switch with the later if it's causing any trouble (it should have the same effect). I haven't used the display or visibility properties to hide the radios, as hidden inputs don't receive focus (i.e. pressing tab skips them).

Also forgot to add a comment for some CSS lines (for explanation). In wp-admin/css/themes.css I've added:

Make clear that wp_get_custom_css() and wp_get_custom_css filter are specifically for obtaining the value to render/display. Eliminate use of wp_get_custom_css() when getting the setting value. Use the underlying post_value directly when is_previewed.

Move anonymous functions handing JS previewing for custom_logo, custom_css, and background into named functions on the wp.customize.settingPreviewHandlers to allow plugins to override/extend preview logic.

Update _custom_background_cb to always print a style tag wen in the customizer preview, and update background preview logic to replace existing style element instead of appending a new style to the head so that background changes don't unexpectedly override any Custom CSS in the preview's stylesheet cascade.