WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#13617 closed defect (bug) (worksforme)

Invisible Non-JS-enabled Menu Tabs

Reported by: filosofo Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Menus Keywords: ux-feedback close
Focuses: Cc:

Description

With JavaScript disabled, the non-current and non-create-new menu tabs are invisible.

The idea obviously was that having them be visible would take up too much width on smaller screens. The problem is that there's no way to navigate to the invisible tabs.

Patch shortens tabs for non-js situations, so at least the first few letters are there with a link (to the active tab and its regular, longer display title).

Attachments (1)

show-truncated-nonjs-tabs.13617.diff (1.7 KB) - added by filosofo 7 years ago.

Download all attachments as: .zip

Change History (12)

#1 @nacin
7 years ago

I recognize that we didn't implement it, but I recall koopersmith bouncing around the idea that in non JS, the user would see only one tab at a time, with a select element next to it that would act as a jump menu (with a button of course, given there being no JS).

Anyway, patch seems sensible, but what happens when there are more menus than horizontal space allows? That was partially the thought behind the select element, though is imagine that may have been rejected for UX reasons.

#2 @filosofo
7 years ago

Maybe the best idea would be to show just the current, arrow to next, and new links. The arrow to next could be hidden for JS-enabled.

#3 @filosofo
7 years ago

Or maybe for non-js it would be better to have a horizontal scrollbar to handle overflowing tabs.

#4 @filosofo
7 years ago

Another option would be to dump the non-js tabs for the "select menu" dropdown alone.

#5 @ocean90
7 years ago

  • Keywords ux-feedback added; has-patch removed

I think for 3.0 we should leave it as it is and review it in 3.1 again.

#6 follow-up: @nacin
7 years ago

The problem is that there's no way to navigate to the invisible tabs.

I've been playing around with the non-JS menus and I've noticed there is indeed a "Select menu" drop-down. (Apparently I didn't pay much attention when testing previously?) Only the current tab is shown along with the + tab, and if you're on the + tab, then obviously no current menu is shown.

I think this is absolutely acceptable.

#7 in reply to: ↑ 6 ; follow-up: @filosofo
7 years ago

Replying to nacin:

I think this is absolutely acceptable.

Except that makes two of us power users who were confused by it initially.

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

Replying to filosofo:

Replying to nacin:

I think this is absolutely acceptable.

Except that makes two of us power users who were confused by it initially.

Hah, well in fairness, I just didn't remember we had added the select box.

#9 @nacin
7 years ago

Perhaps we always show one menu? If you're on the + tab, then the first menu is also shown before it, inactive?

#10 @nacin
7 years ago

  • Keywords close added

Thinking it's probably less intuitive to show tabs inconsistently. We only show the current tab (if there is one) and [+], plus a "Select Menu" drop-down.

*We* are used to the JS workflow. Someone using the non-JS workflow will figure out the main aspects of their workflow pretty quickly.

#11 @nacin
7 years ago

  • Milestone 3.0 deleted
  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.