WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 7 days ago

#22058 new enhancement

Improve custom background properties UI

Reported by: grapplerulrich Owned by:
Milestone: 4.7 Priority: normal
Severity: normal Version: 3.4.2
Component: Customize Keywords: has-ui-feedback needs-patch needs-screenshots
Focuses: ui, accessibility, administration Cc:

Description

For the the custom background display options there is only left, centre and right position. The top and bottom position is missing.

Attachments (20)

custom-background.php (17.1 KB) - added by grapplerulrich 4 years ago.
custom-background
theme.php (52.7 KB) - added by grapplerulrich 4 years ago.
theme.php
22058.patch (4.4 KB) - added by SergeyBiryukov 4 years ago.
A patch with grapplerulrich's changes
22058.2.patch (5.6 KB) - added by grapplerulrich 4 years ago.
22058.patch
22058.3.patch (7.2 KB) - added by grapplerulrich 4 years ago.
22058.2.patch​
22058.diff (10.6 KB) - added by cdog 3 years ago.
22058-editor.png (15.3 KB) - added by cdog 3 years ago.
22058-presets.png (14.4 KB) - added by cdog 3 years ago.
22058-background.png (38.8 KB) - added by cdog 18 months ago.
22058.4.patch (6.9 KB) - added by sebastian.pisula 6 months ago.
Patch for 4.5-alpha-36677
22058.png (60.5 KB) - added by celloexpressions 5 weeks ago.
22058.mobile.png (65.3 KB) - added by celloexpressions 5 weeks ago.
22058.gif (7.6 MB) - added by celloexpressions 5 weeks ago.
With 22058.1.diff.
22058.1.diff (22.9 KB) - added by celloexpressions 5 weeks ago.
See 28.
22058.2.png (54.7 KB) - added by celloexpressions 4 weeks ago.
Tweak colors to soften UI, see 22058.2.diff.
22058.2.diff (23.0 KB) - added by celloexpressions 4 weeks ago.
Tweak colors, ensure that background position control is displayed in 3 columns.
22058.before.png (52.8 KB) - added by celloexpressions 4 weeks ago.
Existing UI in 4.6 (dates to WordPress 3.4 with the image control changing in 4.1).
Screen Shot 2016-07-30 at 4.08.53 PM.png (32.0 KB) - added by melchoyce 4 weeks ago.
position-9-point-grid.png (785 bytes) - added by FolioVision 7 days ago.
Position 9 point Grid Radio Button Style
position-9-point-grid-in-context.png (37.8 KB) - added by FolioVision 7 days ago.
Position 9 point Grid in context

Change History (68)

#1 @SergeyBiryukov
4 years ago

  • Component changed from Themes to Appearance

#2 @MikeHansenMe
4 years ago

  • Cc mdhansen@… added

Related post on the forum http://wordpress.org/support/topic/twenty-ten-align-background-to-bottom


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.

#3 @grapplerulrich
4 years ago

  • Keywords 2nd-opinion added

I created a solution. I attached the two files that I edited.
Here is the test site I am running on.
http://www.grappler.tk/wpdev/

This is my first edit so please bear with me.

#4 @SergeyBiryukov
4 years ago

  • Keywords needs-patch added

Rather than full files, you can submit a patch using Subversion:
http://make.wordpress.org/core/handbook/submitting-a-patch/

@grapplerulrich
4 years ago

custom-background

@grapplerulrich
4 years ago

theme.php

#5 @grapplerulrich
4 years ago

I have changed the files to patches.
Here is a screenshot of the admin view.
http://pix.am/LSq0/

I tested in in IE7-9, Opera, FF and Chrome on Win7 and it works.

@SergeyBiryukov
4 years ago

A patch with grapplerulrich's changes

#6 @SergeyBiryukov
4 years ago

  • Keywords has-patch added; needs-patch removed

#7 @MikeHansenMe
4 years ago

Tested the patch and it works well. We need to also add this to customizer.

@grapplerulrich
4 years ago

22058.patch

#8 @grapplerulrich
4 years ago

I have added the patch with the customizer. Here is a screenshot.
http://pix.am/dPVz/

#9 follow-up: @MikeHansenMe
4 years ago

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

#10 in reply to: ↑ 9 @grapplerulrich
4 years ago

Replying to MikeHansenMe:

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

What tool do you use to minifiy the js?

#11 @MikeHansenMe
4 years ago

Set define( 'SCRIPT_DEBUG', true); then edit the dev.js file instead of the min file.

@grapplerulrich
4 years ago

22058.2.patch​

#12 follow-up: @grapplerulrich
4 years ago

@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?

#13 in reply to: ↑ 12 @MikeHansenMe
4 years ago

Replying to grapplerulrich:

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

#15 follow-up: @MikeHansenMe
3 years ago

Patch still applies but tested again and the changing the vertical position to center shows no change. It does save the change but does not show the change immediately as the horizontal change does.

Last edited 3 years ago by MikeHansenMe (previous) (diff)

@cdog
3 years ago

#16 in reply to: ↑ 15 @cdog
3 years ago

Replying to MikeHansenMe:

Patch still applies but tested again and the changing the vertical position to center shows no change. It does save the change but does not show the change immediately as the horizontal change does.

Please check: attachment:22058.diff. I've refreshed the patch and filled out missing parts.

#17 follow-up: @MikeHansenMe
3 years ago

Patch does not seem to show the change when center or bottom are selected.

#18 in reply to: ↑ 17 @cdog
3 years ago

Replying to MikeHansenMe:

Patch does not seem to show the change when center or bottom are selected.

I'm testing it in Firefox 16 with Twenty Eleven and it works as intended, both from Theme Customizer and Appearance > Background.

#19 follow-up: @MikeHansenMe
3 years ago

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.

#20 in reply to: ↑ 19 @cdog
3 years ago

  • Keywords needs-testing added

Replying to MikeHansenMe:

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.

#21 follow-up: @MikeHansenMe
3 years ago

I am running the most current trunk version(3.6-beta1-24023) and reverting all patches prior to testing. Then applying your patch 22058.diff

Please see the video for explanation
http://bit.ly/11CSUBC

Last edited 3 years ago by MikeHansenMe (previous) (diff)

#22 in reply to: ↑ 21 @cdog
3 years ago

Replying to MikeHansenMe:

Please see the video for explanation
http://bit.ly/11CSUBC

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!

#23 follow-up: @bpetty
3 years ago

I'm seeing the same thing as MikeHansenMe in Chrome 25.0.1364.160.

... and yes, I'm using SCRIPT_DEBUG.

#24 in reply to: ↑ 23 @cdog
3 years ago

Replying to bpetty:

I'm seeing the same thing as MikeHansenMe in Chrome 25.0.1364.160.

... and yes, I'm using SCRIPT_DEBUG.

After applying the patch go to Appearance > Background (or Customize). Then press Ctrl + F5 to reload (override cache) and try uploading an image again. Please let me know if it helps.

@cdog
3 years ago

@cdog
3 years ago

#25 @cdog
3 years ago

  • Cc catalin.dogaru@… added
  • Keywords ui-feedback ux-feedback added

Current patch still applies but I'm not really satisfied with the growing list of radio buttons that are complicating too much the user interaction. I've attached two concepts illustrating variations of the idea that could improve the interface and provide a more engaging experience.

attachment:22058-editor.png puts accent not only on functionality but on UI improvements too.

attachment:22058-presets.png simplifies the idea even more exposing only common background settings presets. It's not as flexible as the first solution but it's much easier to use.

What do you think and which one do you prefer? Would it improve the current implementation?

Version 1, edited 3 years ago by cdog (previous) (next) (diff)

#26 follow-up: @helen
18 months ago

  • Focuses ui administration added
  • Keywords 2nd-opinion has-patch needs-testing ui-feedback ux-feedback removed

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.

#27 in reply to: ↑ 26 @cdog
18 months ago

helen, great! What do you think of attachment:22058-background.png?

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


18 months ago

@sebastian.pisula
6 months ago

Patch for 4.5-alpha-36677

@celloexpressions
5 weeks ago

See 28.

#29 @celloexpressions
5 weeks ago

  • Keywords has-patch ui-feedback needs-testing added
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Custom background vertical position to Improve custom background properties UI

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.

#30 @celloexpressions
5 weeks ago

#26386 was marked as a duplicate.

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


5 weeks ago

#32 @afercia
5 weeks ago

  • Focuses accessibility added

#33 @FolioVision
4 weeks ago

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.

@celloexpressions
4 weeks ago

Tweak colors to soften UI, see 22058.2.diff.

@celloexpressions
4 weeks ago

Tweak colors, ensure that background position control is displayed in 3 columns.

@celloexpressions
4 weeks ago

Existing UI in 4.6 (dates to WordPress 3.4 with the image control changing in 4.1).

#34 @celloexpressions
4 weeks ago

  • Keywords has-screenshots added

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.

#35 @FolioVision
4 weeks ago

@celloexpressions

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.

#36 @celloexpressions
4 weeks ago

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.

#37 @afercia
4 weeks ago

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:

https://cldup.com/gAuSSGy4qe.png

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.

Additional considerations:

  • icon-only controls are tricky and ideally icons would need a text label
  • whether they're going to be radio buttons or buttons, they need to be grouped in fieldsets with a legend
  • proper fieldsets and legends would also allow to simplify the labels: no need to repeat "Set Tile Background to...", "Set Tile Background to...", "Set Tile Background to..." etc. for each option
  • 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

https://cldup.com/KIY1_IFcf2.png

Last edited 4 weeks ago by afercia (previous) (diff)

#38 @melchoyce
4 weeks ago

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.

https://core.trac.wordpress.org/ticket/22058#comment:26 is a much easier to understand approach, IMO. I'm also attaching what WordPress.com does, for comparison.

#39 @karmatosed
4 weeks ago

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.

#40 @FolioVision
3 weeks ago

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?

#41 @karmatosed
2 weeks ago

  • Keywords has-ui-feedback added; ui-feedback removed

#42 @celloexpressions
8 days ago

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.

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


7 days ago

#44 follow-up: @helen
7 days ago

Talked through this a bit in design chat, the proposals and examples have been really helpful in figuring out what actually needs graphical representation and what doesn't. Here's what I'm thinking:

  1. Image control
  2. Background size: radio or dropdown with Original, Fit to screen, Fill screen.
  3. Repeat: checkbox, checked by default.
  4. Scroll with page: checkbox, checked by default.
  5. Start position: graphical helper, such as in 22058-background.png.

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:

http://s.hyhs.me/h7RR/image.png

Last edited 7 days ago by helen (previous) (diff)

#45 in reply to: ↑ 44 @FolioVision
7 days ago

Replying to helen:

  1. Start position: graphical helper, such as in 22058-background.png.

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:

http://s.hyhs.me/h7RR/image.png

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.

Position 9 point Grid Radio Button Style

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

Position 9 point Grid in context

Last edited 7 days ago by FolioVision (previous) (diff)

@FolioVision
7 days ago

Position 9 point Grid Radio Button Style

@FolioVision
7 days ago

Position 9 point Grid in context

#46 follow-up: @Presskopp
7 days ago

@FolioVision: I like this!

Don't beat me, but what about adding cover & contain?

#47 in reply to: ↑ 46 @helen
7 days ago

Replying to Presskopp:

Don't beat me, but what about adding cover & contain?

Please read my comment above - background size is covered.

#48 @celloexpressions
7 days ago

  • Keywords needs-patch needs-screenshots added; has-patch needs-testing has-screenshots removed
  • Milestone changed from Future Release to 4.7

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.

Note: See TracTickets for help on using tickets.