WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 17 months ago

#35505 new defect (bug)

Navigation tabs styling inconsistencies

Reported by: Cybr Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4.1
Component: Administration Keywords: has-screenshots
Focuses: ui Cc:

Description

This is a follow-up to #34214.

Still an issue at max-screen width 600px (mobile).

Attachments (2)

gt600px.jpg (26.7 KB) - added by Cybr 5 years ago.
600px+
lt600px.jpg (31.3 KB) - added by Cybr 5 years ago.
Below 600px

Download all attachments as: .zip

Change History (9)

#1 @afercia
5 years ago

  • Keywords reporter-feedback added

@Cybr thanks for your report. Could you please describe the inconsistencies you noticed or, better, upload a screenshot? Thanks very much.

@Cybr
5 years ago

600px+

@Cybr
5 years ago

Below 600px

#2 @swissspidy
5 years ago

  • Keywords has-screenshots added; reporter-feedback removed

I guess you mean that the tabs look more like buttons on mobile?

It was mentioned in #34214 but not addressed, suggesting that this is intended and not a bug per se. I think it's fine as is. On small screens you don't have enough space to display them as tabs.

#3 @Cybr
5 years ago

@swissspidy
It was mentioned, alas, as you also say: not discussed/addressed. An open discussion would be a great. So, here's my view:

I tend to disagree and it feels like a bug to me. As it's using the same classes many plugins use to create tabs within metaboxes, it all falls apart and looks broken/apart from everything, which is creating an inconsistent experience.

They still very much look like buttons when still having the bar beneath (like they had previously). Reducing the margin-right by a bit as well as reducing the font size gradually will also solve a lot of cropping issues. Easily allowing for about 6 words/buttons.

It's eventually up to the plugin/theme authors what to do with this, but to me it's an unexpected "feature" which has suddenly been added/removed without any good notice (and is breaking mobile layouts).

I believe at least the fine line should still be in place, as it's a separator for what's the menu and what is the changing interface. I also think the nav tab wrapper should still be a block. As other words are floating right next to the buttons now with some configurations I've seen.

Last edited 5 years ago by Cybr (previous) (diff)

#4 @afercia
5 years ago

Worth noting that in the About/Credits/Freedoms screens the "tabs" always looked like buttons on small screens, see screenshot on the left. So the tabs styling was just made consistent with that existing pattern. On the right, the obvious reason why tabs can't be displayed as "tabs" on small screens.

https://cldup.com/pmDnOiV6JQ.png

Also, as far as I know, the navigation tabs were never meant to be used by plugins. If plugins authors decide to use core CSS rules, they should be aware they can change in any moment. The relevant part in common.css is still commented as "Experimental" :)

Of course any suggestions and improvements are welcome but since we can't predict the width and the number of the tabs, it's nearly impossible to find a solution that will fit all the possible scenarios. I'd say that at some point, under a certain viewport width, they just need to be displayed differently.

I also think the nav tab wrapper should still be a block. As other words are floating right next to the buttons now with some configurations I've seen.

Not sure how this can happen since WP 4.4 uses .nav-tab-wrapper:after to clear the floats and trunk recently introduced a new generic CSS rule to clear floats: wp-clearfix with some CSS back compatibility see [36171]. Would be useful to know on which version and with which plugin you noticed text wrapping around the tabs.

#5 follow-up: @Cybr
5 years ago

The floating problem is seen on a premium plugins that was probably trying to fix WP3.x stuff with some weird html elements. Further inspection shows that recently updated ones which have a lot of feedback going on don't have these problems.

You're right, these nav-tab-wrapper elements are supposed to be on top of pages, not within metaboxes. It's also much too dependent on Javascript when doing so. Thanks for reminding me :).

Although the left pane is gorgeously done so, I'm not so sure if a line 7 or 14px below it would be an improvement, but that's up to the designers from here on out :).

I'd say that at some point, under a certain viewport width, they just need to be displayed differently.

Exactly! I think some nice improvements would be static paddings/margins left and right. Creating a block like experience. I'm not sure if you can "text-justify" the blocks, but that could be lovely.

Last edited 5 years ago by Cybr (previous) (diff)

#6 in reply to: ↑ 5 ; follow-up: @afercia
5 years ago

Replying to Cybr:

Exactly! I think some nice improvements would be static paddings/margins left and right. Creating a block like experience. I'm not sure if you can "text-justify" the blocks, but that could be lovely.

Hm do you mean full width blocks (100% width) stacked on top of each other on smaller screens? Yep that could work for smartphones in portrait orientation, definitely something to consider.
By the way these tabs will probably change in the next future. For accessibility and semantics they should use a better markup. Currently they're just links inside a div while they should probably be a navigation element.

#7 in reply to: ↑ 6 @Cybr
5 years ago

Replying to afercia:
It looks like that these tabs should only be used for explicit full-page canonical "a href" navigation.

If this holds true, might I suggest a new feature?
e.g. Radio-button-like tabs for plugin/theme authors to use. Same layout as the current nav-tabs, maintaining the bar beneath. To be used within metaboxes and/or tabbed state pages, without the need of JavaScript (i.e. Accessible). Maybe even to be used on the front-end.

As I need to move away from these ever changing tabs, I'll be sure to write a few functions regarding within a month or two, which will be pushed in the plugin repo, open for everyone :).

I'll be more than happy to contribute :).

Note: See TracTickets for help on using tickets.