Admin UI: header container border causing boxy layouts

[simison]

The header component always has a border under it, causing some layouts sometimes look needlessly "boxy" — mainly when the container has tabs which also have full width border, such as "Fonts" page:

Fonts

With border	Without border

On containers where the DataViews filters bump directly onto the header, such as Pages with table view, the border makes sense:

Pages

With border	Without border

When using WP Build and Admin UI components in a plugin, we had more of a mixture scenario (tabs + DataViews filters on the same line):

With border

Without border

Ideas

• We always remove the border and accept somewhat "floating" outcome for DataViews filters, but less boxy overall. (PR to test with Remove border-bottom from admin-ui page header #75429)

• We allow injecting tabs (and other content) into the header, similar to Actions, and the Tabs & Header border can collapse into one.

[simison]

@jameskoster @jasmussen, really not urgent issue at all, but you might have a ready thought perspective on my questions. :-)

[jasmussen]

My brief take is that this particular screen type is more tech than design at this point, and so PRs are welcome. As far as I see it, much of the design that can be relevant to this is indeed the site editor, so patterns from there can perhaps be transplanted here.

[simison]

Cool :-) Mostly wanted to get 👍 that moving away from the extra border for the case is ok.

[jasmussen]

That's my instinct, yes. I think there's an open question why it's there in the Header component, if we're reusing that, so if Jay has context there I'll defer to him.

[jameskoster]

Good topic. One consideration is that the header should be sticky. As the user scrolls, introducing a border can help separate the header from the page content. That border doesn’t necessarily need to be permanent—it could appear only once scrolling begins. I believe Modal behaves this way currently.

Another question is whether the submenu is treated as part of the header, and what its final visual design should be. If the submenu is included within the header, the current tab-like styling almost requires a border for the design to feel coherent. However, because the submenu functions as navigation, I don’t think it should visually resemble tabs due to the different interaction pattern and semantic meaning. Users should be able to visually recognise tabs vs navigation at a glance.

My current line of thinking is that submenu should have its own distinct design, and in this context be rendered insied the header. The header’s bottom border would then appear only on scroll.

[simison]

@jameskoster, looking at this again and considering what to implement in Page.

Solution could be allowing passing Tabs to Page, and it'll know what to do with the header styles?

The header’s bottom border would then appear only on scroll.

I think this makes sense if the canvas background color is something else than white, but e.g. in Fonts (and any page build with Page currently it'll always be white:

[jameskoster]

Since these tabs control the entire page content, it probably makes sense for them to live inside the header IE as part of Page.Header. That would also ensure they inherit the existing sticky behaviour and any border logic we implement.

However, this raises a broader question: should these truly be tabs (ARIA tab pattern) from a semantic perspective? On DataView pages, we intend to use link-based navigation to switch between views because they have dedicated urls. We should probably align on this because supporting both navigation links and tabs will add a lot of complexity.

[simison]

@jameskoster other things to consider with these Page component design questions:

• Core notice banners; while not pretty, they're also used for things like upsells on 3rd party plugin pages.
• Footer credits:
  
• Hello Dolly plugin placement (it's a plugin but ships with every WP)

The alternative is to say we won't support those things in WP pages going forward.

[jasmussen]

The alternative is to say we won't support those things in WP pages going forward.

There's a larger picture we can explore, where the version number is integrated into the sidebar on the left, and arguably the WordPress.org link is already integrated into the dashboard, and the W dropdown menu. But I acknowledge, that's a larger picture, a nearer term solution might need integration where it exists at present. An option:

I'm not really a fan of that option, sharing it only in case it unlocks an immediate path forward. If it doesn't, we should explore more holistically.

[simison]

Could be a good spot to include "WordPress v6.9.1" for WP pages and "My Plugin 1.0" for 3rd party pages.

[jameskoster]

Yeah I'd probably consider that content to be outside the page content and part of the broader chrome. An example of the page footer would imo be something like the sticky bulk action/pagination tools on DataViews pages: