WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#24882 closed enhancement (wontfix)

Twenty Fourteen: Left menu / bar column -- have it be sticky-ish.

Reported by: georgestephanis Owned by:
Milestone: Priority: low
Severity: normal Version: 3.8
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Currently on a long page, when you keep scrolling down, it's hard to access the content in the left column. It's blank, and you have to scroll all the way back up to the top of the page to access it. Let's make it stick:

Proposed Logic:

If the column content's height is less than the browser height

Easy. Have it stick to the top of the screen.

If the column content's height is taller than the browser height

If the user would scroll down further than the left content, have it stick the bottom of the content to the bottom of the screen.

If the user begins to scroll back up, leave it as-is, let it move with the main column.

When the user reaches the top of the left side content, stick the top to the top of the window, and have it follow them.

The idea is to not stick/reposition it unless you need to, to keep it in view.

Attachments (1)

24882.diff (1.8 KB) - added by georgestephanis 8 years ago.

Download all attachments as: .zip

Change History (9)

#1 @georgestephanis
8 years ago

24882.diff accomplishes this, but has an event that fires on $(window).scroll()

Running on scroll can be a bit of a performance hit, so I'd prefer to see it short-circuit and return early most times, which means instead of manually setting the top via .css() it will need to toggle on and off fixed positioning when it's at the edges, and switch to relative positioning when it's in the middle.

If there's concern about the JS still being too weighty, we could run a test to determine if the browser is lagtastic, and not do it for those browsers. Or include a toggle in the admin to let the user determine whether they feel this to be a worthwhile offset.

#2 @MikeHansenMe
8 years ago

  • Keywords has-patch added; needs-patch removed

#3 @georgestephanis
8 years ago

I'm not quite satisfied with the current patch, I think it can do better with short circuiting and the like.

#4 @SergeyBiryukov
8 years ago

  • Version set to trunk

#5 @celloexpressions
8 years ago

Current patch works but is incredibly laggy in both Chrome and IE10 (works great in Firefox). I'd love to see this happen, but it definitely needs work more broadly. While it's fixed, we should probably just leave it with position: fixed and top: navbar offset or bottom: 0 and only change anything if the scrolling changes direction (sounds like what you had in mind with short-circuiting).

#6 @lancewillett
8 years ago

  • Priority changed from normal to low

Let's discuss this idea and approach at next office hours. I'm leaning towards "wontfix" just because it could add more UX issues than it solves. Also interested in hearing Takashi's reaction to it.

#7 @karmatosed
8 years ago

  • Cc karmatosed@… added

#8 @lancewillett
8 years ago

  • Keywords has-patch removed
  • Milestone 3.8 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Discussed and decided to close as wontfix, in Tue Sep 3 office hours: log.

Note: See TracTickets for help on using tickets.