Site Health: improve the header elements horizontal centering

[afercia]

In the Site Health pages, the elements in the header aren't horizontally centered.

Not a blocker but visually it's slightly disturbing because the alignment looks "off".

I guess it's because of a mix of design choice and implementation details e.g.:

• the "score counter" on the right of the main title makes the title not centered
• the nav menu items can't be centered because of the CSS implementation

Also, while this is visible in the default language (English), it's even more evident with languages that use strings with a different length. See the attached screenshots, where the vertical red line is placed exactly in the middle of the content area.

[Clorith]

This is not the worst thing to fix, but has other considerations to keep in mind which I suspect mostly boils down to preferences:

Right now, it's centered based on the whole top area (including the "score counter"), so the text may feel offset, but as a whole it is actually in the center.

On the other hand, if we change it, the text will appear centered, but the score will noticeably "poke out" on the side then.

[xkon]

As an extra note on this, the page title uses an .health-check-header h1 { margin: 1rem 0.8rem; } that pushes the title a bit towards the "right" side since the score counter doesn't have a right margin as well to balance the same "outter" spacing. Setting a margin: 1rem 0.8rem 1rem 0; to the h1 sets a more correctly "centered" alignment to the overall elements of health-check-title-section, but again it might seem "off" :)

[afercia]

To make the two menu items have the same width irrespectively of the length of their text, these two lines of CSS could be used on the nav element. Works nicely in modern browsers:

display: inline-grid;
grid-template-columns: 1fr 1fr;

See attached screenshot below.

[afercia]

nav items same width

[Clorith]

I'm marking this for 5.2.1, it makes sense to tackle then as we will be evaluating the pass percentages as well at that time.

[desrosj]

If #47046 removes the grading circle (which appears to be where the consensus on that ticket is heading), would this need any further action? In my testing, it seems the tabs would then be centered to the middle of the heading. If this is true, I think this can be closed out and mentioned/tackled on #47046 instead.

@afercia can you confirm?

[afercia]

@desrosj regardless of the grading, the tabs are not centered. Simply because their width is based on their content. I's more evident in languages other than English.

Only way I can think of to center the tabs is giving them a min-width which wouldn't work with very long translations anyways. Or use the CSS posted above.

[Clorith]

I just tested the CSS above, and I kinda like it, it felt more natural than variable length items. It does rely on there always being no more than 2 items, but I think that's fine, we can up the limit if there at any stage becomes a need for another entry, but I don't foresee one anytime soon.

[tinkerbelly]

The design team ​this briefly during a triage session today.

It sounds like the key question here is: “Should navigation tabs be of equal or variable width?”

We'll want to be certain that this is a robust pattern that can apply to other parts of the interface that may use it—for instance, Gutenberg's sidebar. With that in mind, it seems that variable width tabs are the most flexible solution, both in terms of accommodating different use cases, languages, string lengths, and zoom settings.

Unfortunately, this does mean that, in some cases, the visual display may suffer a bit. This feels like an okay trade-off for increased usability and flexibility here, rather than prioritising visual balance.

A potential workaround if this is an unacceptable visual regression could be to look into left-aligning these title headers, rather than centre-aligning them. This would, again, require testing across devices, settings, and languages to ensure we have a pattern that's reusable across different interfaces and flows.

[afercia]

Just to clarify, the proposed CSS that uses inline-grid still makes the tabs have a variable width :) Both tabs will have the width of the largest one. This also automatically centers them horizontally.

You can see this in the attached in browser editing.png​ there the two text strings have different width and the tabs width automatically adjust to the largest one. This is still "flexible" width and, at the same time, equal width.

[desrosj]

This still needs a patch. With 5.2.1 RC today or tomorrow, let's move this to 5.2.2.

[dkarfa]

Patch

[davidbaumwald]

@dkarfa Thanks for the patch. I believe this still needs some work. Setting a static width will be problematic with longer tab headings. See screenshot. I like @afercia's suggestion to use grid/flex so that the widths are a little more text-length agnostic while remaining centered.

[davidbaumwald]

Site Health Tabs Overflow w/ Long Headings

[afercia]

46881.diff​ uses inline-grid. These two tabs are hardcoded, there are no filters and no ways to add more tabs, at least for now. This means there are only 2 tabs and we can safely use grid-template-columns: 1fr 1fr;. If new tabs will be added in the future, we'd just need to update this value.

Some testing would be nice:

• try with different text length
• hint: using your browser's dev tools, you can also add a contenteditable attribute to the tabs and then type longer strings directly in the tabs
• verify the 2 tabs always have the same width regardless of the text length
• verify the 2 tabs are always centered in the page
• test on Windows with IE 11

[afercia]

Test using contenteditabe

[davidbaumwald]

Replying to afercia:

46881.diff​ uses inline-grid. These two tabs are hardcoded, there are no filters and no ways to add more tabs, at least for now. This means there are only 2 tabs and we can safely use grid-template-columns: 1fr 1fr;. If new tabs will be added in the future, we'd just need to update this value.

Some testing would be nice:

• try with different text length
• hint: using your browser's dev tools, you can also add a contenteditable attribute to the tabs and then type longer strings directly in the tabs
• verify the 2 tabs always have the same width regardless of the text length
• verify the 2 tabs are always centered in the page
• test on Windows with IE 11

Looks good in Chrome on Windows.

One other thing to keep in mind that #47225 is milestoned for 5.3 and that does add actions to prepend/append the Site Health tabs with additional content. This could be used include more tabs, which would cause wrapping due to the grid template(see screenshot).

[davidbaumwald]

Site Health tabs w/ grid and additional tabs

[afercia]

@davidbaumwald thanks, I didn't know about the plans to add filters for new tabs. That can be solved by providing CSS classes based on the number of tabs and additional CSS rules.

[Clorith]

I had no idea someone had milestoned anything relating to filtered tabs, see also ​https://github.com/WordPress/health-check/issues/344 which looks at how to approach this if the navigation were to be filtered.

As for the solution, I think it's the way to go as @afercia mentions with the equal size colums. I feel it should be noted that it feels like the spacing becomes very large between the two entries (as shown in the example in typing.gif​ ), but that's likely going to be rare when both strings are translated, so I'm thinking we accept the solution in 46881.diff​.

[afercia]

46881.diff​ will need ​the IE-old syntax to work witn Internet Explorer 11. /Cc @joyously

[afercia]

46881.2.diff​ adds the CSS syntax necessary for Internet Explorer 11.

See in the screenshot below:

• testing in Italian so that the tabs have text with clearly visible different length
• the red border is for testing purposes, to highlight the tabs have the same width and are horizontally centered

The resulting CSS is not terrible but is not that great either. I'm not aware of any other CSS method to horizontally center elements of unknown, flexible, width. If anyone comes up with a simpler solution, that would be very welcome :)

[audrasjb]

46881.2.diff looks good on my side @afercia
Thanks for adding IE11 support. I think we are good to go :-)

[afercia]

In 45522:

Administration: Improve the horizontal centering of the Site Health tabs.

Props dkarfa, davidbaumwald, Clorith, tinkerbelly, afercia.
Fixes #46881.

[afercia]

Reopening for 5.2.2.

[afercia]

In 45523:

Administration: Improve the horizontal centering of the Site Health tabs.

Props dkarfa, davidbaumwald, Clorith, tinkerbelly, afercia.
Merges [45522] to the 5.2 branch.
Fixes #46881 for 5.2.2.

[ramiy]

Using grid may cause issues in the future. You set grid-template-columns: 1fr 1fr;.

But if plugin developers will add custom menu items (See: https://core.trac.wordpress.org/ticket/47225), the design will break.

We need a better solution that will take into account not a fixed amount of items.

[afercia]

@ramiy right. Your point is valid and was previously discussed. So far, there's no way to add tabs. When plugins will have the ability to add tabs, this part will need to be adjusted. One option is to print out via PHP additional CSS classes with the tabs count and provide a set of CSS rules to take that into account. Something similar to what the image galleries use.

As said in a previous comment, I'm not aware of any other CSS method to horizontally center elements of unknown, flexible, width. If anyone knows better methods, they're very welcome. I'd suggest to not anticipate though, and take care of this only when there will be the ability to add more tabs in #47225.