Make WordPress Core

Opened 10 years ago

Closed 3 years ago

#30359 closed enhancement (wontfix)

Widget Areas should stick to the browser viewport

Reported by: dd32's profile dd32 Owned by: ajensen's profile ajensen
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: Widgets Keywords: good-first-bug has-patch
Focuses: ui, javascript, administration Cc:

Description

Similar to what we've done with the admin menu and meta boxes on the post screen, when you scroll down the list of available widgets, the widget areas should stay within the viewport if possible instead of simply having white space visible.

This is far more obvious on a site which has lots of widgets (such as WordPress.com) which results in dragging widgets from the lower end of the available section to an area difficult.

We do have alternative methods of adding widgets (Clicking and the Customizer) but I think this would be a huge win for the Widget screen.

Attachments (5)

30359.diff (335 bytes) - added by chetan200891 7 years ago.
Created patch so Widget Areas stick to the browser viewport.
admin-sticky-widgets.gif (3.2 MB) - added by GaryJ 7 years ago.
Screen capture of a large number of (sticky) widget areas means the bottom ones aren't accessible without scrolling all the way to the bottom of the active + inactive widgets.
30359.2.patch (1.1 KB) - added by ajensen 7 years ago.
30359.patch (1.1 KB) - added by ajensen 7 years ago.
widgets.png (29.6 KB) - added by cleancoded 6 years ago.

Change History (24)

#1 @helen
10 years ago

  • Focuses ui javascript added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Let us do so.

#2 @johnbillion
10 years ago

  • Version changed from trunk to 4.0

#3 @srikat
7 years ago

Hi,

We can do this easily by loading the following CSS on the /wp-admin/widgets.php page:

@media only screen and (min-width: 481px) {

	.widget-liquid-right {
		position: -webkit-sticky;
		position: sticky;
		top: 42px;
	}

}

#4 @dd32
7 years ago

  • Keywords good-first-bug added

Looking at the CanIUse Browser support for position: sticky it looks like it's got a good enough coverage to be used in core now.

Marking as good-first-bug if someone would like to wrap the above into a patch. I believe our auto-prefixer should take care of -webkit-sticky too, so that can be skipped.

#5 @dd32
7 years ago

https://cloudup.com/cE6zrybaNOF is a demo of this in operation from @srikat as well.

@chetan200891
7 years ago

Created patch so Widget Areas stick to the browser viewport.

@GaryJ
7 years ago

Screen capture of a large number of (sticky) widget areas means the bottom ones aren't accessible without scrolling all the way to the bottom of the active + inactive widgets.

#6 @dd32
7 years ago

Thanks @GaryJ I was fearing that was the situation :)

Might need some JS after all to only apply when the bottom of the sidebars is visible too.

That still feels less janky than it currently is though for the vast majority of others.

#7 follow-up: @galbaras
7 years ago

Why not wrap the widget areas in an independently scrollable container? This way, we can position the right hand side and the left hand side just the way we like them and then drag and drop with ease.

The container can be sticky, but its contents not.

#8 in reply to: ↑ 7 @dd32
7 years ago

Replying to galbaras:

Why not wrap the widget areas in an independently scrollable container? This way, we can position the right hand side and the left hand side just the way we like them and then drag and drop with ease.

Are you suggesting multiple scrollable areas? independent of on another? that doesn't seem like a very nice user experience to me.

#9 @galbaras
7 years ago

I've tried adding "overflow-y: scroll; overflow-x: hidden; height: 90vh;" to .widget-liquid-right seems to do the trick, but 90vh may not be ideal at every width.

Also, this needs to be combined with setting .widget to "max-width: 100%;" and removing the assignment of margin-left to some negative number when the widget is opened, which is done in a script.

#10 @srikat
7 years ago

Here's a link to the plugin which adds the CSS that I shared in post 3: https://github.com/srikat/admin-sticky-widget-areas

I'll try suggestions of @galbaras and see how it goes..

@ajensen
7 years ago

#11 @ajensen
7 years ago

Hello,

I’ve added a patch with @srikat CSS code as well as @galbaras suggestions. I found the two independent scrolling areas to be more efficient then the previous layout with both a small and large number of widgets in the left column. I also asked a friend to use it and she found it to be easy and functioning. Although it worked on my viewport size I was not able to test it on larger screens.

Also I was unable to understand and implement @galbaras’s suggestions where he says
"removing the assignment of margin-left to some negative number when the widget is opened, which is done in a script"

Lastly, this is my first patch.

#12 follow-up: @sboisvert
7 years ago

@ajensen This is a great first patch!
I really like that you did some user testing with the patch, that's great!

I had a few questions :)
When I look at the patch I see some blank lines being added. Was this intentional?
Can you elaborate on the decision to put the CSS inside widgets.php? Are there other places that might be suitable?

I found @dd32's suggestion:

Might need some JS after all to only apply when the bottom of the sidebars is visible too.

To be a really interesting one. Do you think that's feasible?

#13 in reply to: ↑ 12 @ajensen
7 years ago

Replying to sboisvert:

I had a few questions :)
When I look at the patch I see some blank lines being added. Was this intentional?
Can you elaborate on the decision to put the CSS inside widgets.php? Are there other places that might be suitable?

Thanks so much for the feedback @sboisvert! To answer your questions...

No, those blank lines were not intentional, opps. Also, I decided to place the CSS in the widgets.php in response to @srikat's comment "We can do this easily by loading the following CSS on the /wp-admin/widgets.php page" However, another more fitting place would be in the widgets.css placed properly amongst the other media queries.

Lastly, I definitely think some JS is feasible. I'll be attempting @dd32's suggestion shortly.

#14 @DrewAPicture
7 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to ajensen
  • Status changed from new to assigned

Assigning to mark the good-first-bug as "claimed".

@ajensen
7 years ago

#15 @ajensen
7 years ago

I made an attempt at this with some JavaScript. It's set up so that if the right column is entirely visible in the viewport it will automatically stick. I started another function so that when the bottom of one of the columns is reached it will no longer scroll, but the other column would still scroll. However, I struggled to get the columns to stick after reaching the end. I tried using css to relatively position it and then set the bottom position to 20px, but this did not seem to work when testing it and interfered with the first function.

I'd love to get some feedback if anyone has any helpful advice!

#16 follow-up: @galbaras
7 years ago

It may depend where the cursor is while the scrolling happens, so the sticking of the columns should apply to scrolling over other areas of the page. Otherwise, your sticking code may be ignored as irrelevant for the scrolling target.

For more detailed feedback, perhaps you can share the code somehow.

#17 in reply to: ↑ 16 @ajensen
7 years ago

For more detailed feedback, perhaps you can share the code somehow.

I'v added the code in a patch on my previous comment. Thank you so much for the feedback! It's greatly appreciated.

@cleancoded
6 years ago

#18 @cleancoded
6 years ago

Hi,

The below styling in wp-admin/widgets.php should work to make sticky area.

<style>

@media only screen and (min-width: 481px) {

	.widget-liquid-right {
 		 position: sticky;
 		 top: 45px;
	}

}

</style>

Have a look on below screenshot to view output for me.


#19 @peterwilsoncc
3 years ago

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

The widgets screen was replaced in 5.8 and the legacy widgets screen placed in maintenance mode. As this is an enhancement, I'm going to close the ticket off.

Note: See TracTickets for help on using tickets.