Change 778356 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] Tabs: Design review follow-up adjustments

https://gerrit.wikimedia.org/r/778356

@egardner I've reviewed the last patches of the demo and I've updated the task description checking all the corrections done.

I've added a new correction about the separation between tabs since both normal and framed tabs should have a separation of 4px (currently only framed tabs have this separation while normal tabs are glued).

Uncovering from all Tabs design refinement patches, from my POV we have to ensure that a single Tab's interaction area height is 32px for affordance requirement reasons.

Also, we've inherited frameless from OOUI Tabs, but have there opted for the more common in case of Buttons. We should also follow the “quiet” label here.
Additionally, I think we should be explicit in the CSS class and add a --quiet modifier.

I was reviewing the last patch in Safari and I've realized that there is 1px of separation there between tabs and gray divider. I'm going to add it to the Design Review checklist to fix it.

In T303321#7823237, @egardner wrote:

This particular issue has been addressed in the latest patch – tabs beyond the viewport should automatically scroll into view once they become active.

Thanks, that helps. However, I still think the tabs scrolling UX is unclear. There are no scroll bars, there's no indication that you can scroll except for the gradient, and unless you're using a touch screen or track pad it's hard to discover how you can scroll.

In T303321#7879418, @Catrope wrote:

In T303321#7823237, @egardner wrote:

This particular issue has been addressed in the latest patch – tabs beyond the viewport should automatically scroll into view once they become active.

Thanks, that helps. However, I still think the tabs scrolling UX is unclear. There are no scroll bars, there's no indication that you can scroll except for the gradient, and unless you're using a touch screen or track pad it's hard to discover how you can scroll.

@Catrope I agree, for a more accessible tabs we should indicate the scroll with something more than the gradient, also not sure if all laptops or mouses could make the horizontal scroll without buttons. For this reason, I presented during the beginning of the task this other proposal where we combine both arrows and horizontal scroll. I think this would be the most accessible solution for any user and device.

In T303321#7781197, @bmartinezcalvo wrote:

What if we combine both (arrows and scroll)? With this solution our tabs component will be more accessible. We can build it adding Quiet Neutral buttons (icon only) as previous and next controls.

Change 778323 merged by jenkins-bot:

[design/codex@main] Tabs: Fix broken header hover styles in Chrome

https://gerrit.wikimedia.org/r/778323

I've created a new task for the scrolling arrows: T307491

Another issue I just found: the tabs list doesn't specify its own line-height, and in the demo it has line-height: 1.7; because the VitePress styles apply that to all <ul> elements. We may want to consider setting our own line-height, maybe setting it to 20px like we do in MenuItem. I think that would ensure that the tabs list is the same height as shown in the Figma spec (right now it's taller).

A few of the complications resolved in the latest patch (also showing the nifty thin-line solutions path):

• Need to ensure all changed properties are on the Tab link element (with role="tab" assigned), as the browsers have troubles to render state changes consistently, so no Blue500 borders on li elements anymore
• We can't use border for the bottom border, when we apply an all side border to a Tab. As a single border is rendered when all 4 are unequal 0

• As soon as we can't use borders we have to rely on box-shadows for all selected and focus blue emphasize “outlines”
• Due to the rendering of inset box-shadows, we need to exacerbate the border-radius to double in order to get rounded borders on focus

Side-note: There might be edge-casey faulty browser rendering results with the border-radius not being applied to an element without positive border-width applied. At least that was an issue in more ancient browser.

On the gradient mixin, ideally we would not point the selector out at all if it's a start or an end gradient, but just have a before and an after selector. Have updated the gradient a slight bit to make the 24px limit possible, but will wait for the arrow approach by you Roan. The mixin is pretty application-specific and inflexible, we should limit its scope or get rid of it completely in my opinion.

Several nasty details with the current scrollbar treatment:

• Safari's 1px space between selected frameless Tab and the Tab border seems to come from overflow-x: auto on ul.cdx-tabs__list, probably in connection with flex. It's unfixable as long as we need to support scrollbars, everything aside of hiding overflow will result in the pixel gap.
• scrollbar-width: none; is only supported in Firefox > 64 and it's not entirely clear if it does, what it's supposed to do. When we reduce the scrollbar to a 0 we let it only work under certain circumstances enabled (scroll wheel or touch bar available and pointing capabilities given).
• Edge fails the rendering badly, here Edge 18:
  
  , IE/Edge on Trident support a proprietary extension -ms-overflow-style: -ms-autohide which makes it a bit more bearable, still not looking professionally done

Change 778356 merged by jenkins-bot:

[design/codex@main] Tabs: Adjust styles to follow design and simplify selector logic

https://gerrit.wikimedia.org/r/778356

Change 790763 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] Tabs: Apply correct borders on hover/active

https://gerrit.wikimedia.org/r/790763

The spec sheet is ambiguous on whether an already-selected tab should change color when hovered or active. As currently implemented, the answer is no: when you hover or click the selected tab, it doesn't change color. The selected state overrides the hover/active states.

@Volker_E argues that this makes sense because you can't meaningfully interact with the selected tab (clicking it doesn't do anything), but he then wondered whether it makes sense to still show a hand cursor when hovering the selected tab.

Change 790763 merged by jenkins-bot:

[design/codex@main] Tabs: Apply correct borders on hover/active

https://gerrit.wikimedia.org/r/790763

From a question raised by myself, we've agreed in today's DS Design meeting to settle on calling the non-framed Tabs quiet in order to simplify onboarding and not use two terms (quiet and frameless) for nearly equal visual types.

Change 791073 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] Tabs, styles: Rename 'frameless' to 'quiet'

https://gerrit.wikimedia.org/r/791073

Change 791073 merged by jenkins-bot:

[design/codex@main] Tabs, styles: Rename 'frameless' to 'quiet'

https://gerrit.wikimedia.org/r/791073

Apologies if I've missed this in the above comments, has there been any discussion about including an optional icon in the tab?

In WikiLambda we currently have custom tabs with icons that help visually indicate progress.

@Catrope I've checked the component and the 1px separation between selected tab and gray line in Safari has been fixed.

But I've found new things to fix now:

1. When you resize the tabs the 1px between selected tab and gray line appears (in both Safari and Chrome).

2. Also, when you resize the tabs in Safari and the scroll appears, a gray gradient appears (it should be white gradient instead gray gradient) in both Quiet and Framed tabs.

@Catrope I move the task to Ready for Development so you can fix these corrections.

In T303321#7931770, @JKieserman wrote:

Apologies if I've missed this in the above comments, has there been any discussion about including an optional icon in the tab?

In WikiLambda we currently have custom tabs with icons that help visually indicate progress.

I'm cautiously for ability to add icons to tabs labels.
Note, that the icon in the shared screen is not a standard icon and we should only feature icons available in Codex or add them to the library following the icon guidelines if needed.

In T303321#7933820, @bmartinezcalvo wrote:

@Catrope I've checked the component and the 1px separation between selected tab and gray line in Safari has been fixed.

But I've found new things to fix now:

2. Also, when you resize the tabs in Safari and the scroll appears, a gray gradient appears (it should be white gradient instead gray gradient) in both Quiet and Framed tabs.

I can't reproduce this on Safari 15.4 (17613.1.17.1.13). Tried to resize window and scroll and switch between framed/quiet a few times, but it always shows the right gradient. What are the exact steps to end up with grey gradient for you?

In T303321#7933820, @bmartinezcalvo wrote:

@Catrope I've checked the component and the 1px separation between selected tab and gray line in Safari has been fixed.

But I've found new things to fix now:

1. When you resize the tabs the 1px between selected tab and gray line appears (in both Safari and Chrome).

Already shared this in T303321#7915845:

Safari's 1px space between selected frameless Tab and the Tab border seems to come from overflow-x: auto on ul.cdx-tabs__list, probably in connection with flex. It's unfixable as long as we need to support scrollbars, everything aside of hiding overflow will result in the pixel gap.

overflow-x: scroll would be minimizing the gap, but it introduces layouting issues in all other browsers and results in huge visible scrollbars in default Windows setting.

By the way connected Edge 18 issue with scrollbars, the only somewhat non-visible scrollbar rule that I could identify and it is not convincing on a number of levels

.cdx-tabs__list:not( :hover ) {
  -ms-overflow-style: -ms-autohide;
}

which would only show the scrollbar on old Edges on hover with a reflow.

How do others do it?

• Vuetify disables overflow (and with it scrollbars) completely with the arrow buttons.
• Buetify does the same thing as we do, putting overflow-x: auto on the tabs wrapper. Ending up with the same nasty scrollbars on non-macOS as we do.

In T303321#7936291, @Volker_E wrote:

In T303321#7931770, @JKieserman wrote:

Apologies if I've missed this in the above comments, has there been any discussion about including an optional icon in the tab?

In WikiLambda we currently have custom tabs with icons that help visually indicate progress.

I'm cautiously for ability to add icons to tabs labels.
Note, that the icon in the shared screen is not a standard icon and we should only feature icons available in Codex or add them to the library following the icon guidelines if needed.

@JKieserman I agree with @Volker_E these icons look more like process steps than standard icons for tabs. We should study the use case in deep to understand if we need tabs with icons or not. In this case, the icons used in the tabs should reinforce the text so that they are better understood (see example below), they shouldn't indicate process steps or states.

In T303321#7936363, @Volker_E wrote:

In T303321#7933820, @bmartinezcalvo wrote:

2. Also, when you resize the tabs in Safari and the scroll appears, a gray gradient appears (it should be white gradient instead gray gradient) in both Quiet and Framed tabs.

I can't reproduce this on Safari 15.4 (17613.1.17.1.13). Tried to resize window and scroll and switch between framed/quiet a few times, but it always shows the right gradient. What are the exact steps to end up with grey gradient for you?

@Volker_E when you open the tabs in Safari (I have Safari 14.1.2 (16611.3.10.1.6)) and you resize the screen window to make the tabs smaller and let the scroll appear, the gradient of the scroll appears in gray. I send you this video to show you what happens.

@bmartinezcalvo Thanks for the clarification! It might be originated in a very old Safari bug, where Safari doesn't render transparent value carrying gradients correctly.

Change 794048 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] Tabs, tokens, styles: Use `rgba()` over transparent for background color

https://gerrit.wikimedia.org/r/794048

The latest patch in Saf 13:

Note, that we would have to define two more theme tokens:

"transparent-light": {
	"value": "rgba( 255, 255, 255, 0 )"
},
"transparent-dark": {
	"value": "rgba( 0, 0, 0, 0 )"
}

and an update to a decision token value:

"base--transparent": {
	"value": "{ color.transparent-light }"
}

Change 794048 merged by jenkins-bot:

[design/codex@main] Tabs, tokens, styles: Use `rgba()` over transparent for background color

https://gerrit.wikimedia.org/r/794048

@Catrope Should we declare this task's requirements achieved from engineering perspective with remaining

• 1px divider being tackled in T307491: Add arrow buttons for scrolling Tabs header, possibly replacing scrollbar and overflow with JS scrolling
• icon slots for Tabs being further evaluated and discussed in T309673: Tab: Evaluate (and implement) Tab icons

I'd suggest so, in order to keep this task resolvable and reviewable.

Moving Functional Testing of this component out of this current sprint and into the general Team Functional Testing column, in order to focus on current sprint goals, which primarily include preparing Typeahead Search and several other smaller tasks.

A related reason for doing this is to ensure we have time to triage any tickets or followup work that might come from the functional review of this fix.

Will pick up when prioritized for release.

This component has been released; does it still need some amount of QA testing? Moving back into the current sprint board so we can hopefully close it out soon.

Test cases have been documented here. Many thanks to @Volker_E and @bmartinezcalvo for their assistance with clearing up some questions about design.

Product sign-off complete