@MMiller_WMF ready for review

Thanks for thinking of this, @Cntlsn! I think we decided that we need run this by @alexhollender. @Cntlsn, could you make sure that happens?

Thanks, @Cntlsn and @alexhollender. I'm moving this to Ready for Development.

@alexhollender -- your team wants this capability for your potential future work right? I imagine we would engineer it to be part of the general mobile tab capabilities, not just for our team's work.

In T223142#5243876, @MMiller_WMF wrote:

@alexhollender -- your team wants this capability for your potential future work right? I imagine we would engineer it to be part of the general mobile tab capabilities, not just for our team's work.

I agree that it should be part of the component (if such a thing exists). @Jdrewniak any idea if we ended up creating some kind of tab component for the Article/Discussion tags in AMC (T212216)?

If we can't easily get the initial scroll position right, based on the selected tab, another option is to force all tabs on one line but allow each tab label to wrap. Here's what it looks like in Czech:

As a bonus, it makes each tab's tappable area larger and maybe easier to use on a phone.

Change 517107 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/skins/MinervaNeue@master] Make the tabs scrollable horizontally

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

The patch above makes the tabs scrollable in Minerva. If this is undesirable in AMC in general, I can move this code to GrowthExperiments so it applies only when the Homepage is enabled in the userspace (homepage, userpage, talk).

Change 517107 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Make the tabs scrollable horizontally

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

We recently implemented horizontally scrollable "frameless" tabs in OOUI: https://doc.wikimedia.org/oojs-ui/master/demos/?page=layouts&theme=wikimediaui&direction=ltr&platform=mobile#demo-section-other-layouts

We should at least unify the styling of these two implementations if the OOUI version can't be used:

@Esanders I agree that it would be good to unify these. In practice there are two issues with the OOUI tab system, given this example:

• in most of the UI blue indicates a link. It becomes confusing here because "Article" is the selected tab but looks like a link.
• in cases where the tab system is not a primary focus of the page the blue is distracting

I wonder if it would be possible to extend the OOUI component to include some kind of secondary state where the selected tab remains black/gray?

@Cntlsn - please take a look. The screenshots are form iPhone 6S.

First tab sliding:

Second tab sliding:

Thanks @Etonkovidova.
The interaction looks good to me, but one of the specification details doesn't look to be supported:

• When one of the other items in the tabbed menu (user page) is selected, it will be aligned to center

Moving it back to Ready for development for future work.

The dynamic scrolling of the tab area is fragile. It worked with the devices I tested but seem to cause T226112 on @Cntlsn's phone.

I suggest we disable it completely until we can make it better. We would need something similar to OOUI's scrollIntoView that supports scrolling only in one direction (horizontally).

@SBisson -- the reason I felt strongly about this feature is because (according to my phone), all Czech mobile users would see the third tab wrap to the second line, which I thought was a really confusing experience.

We don't know how many users would experience the third tab wrapping to the second line. I know that I experienced it on my phone, but others have not. If it's a lot of users, I think this should block our release. Taking all the options into account, I think it would be better for our initial release to have buggy scrolling tabs than to have the third tab wrap to the next line. If the concerns about the scrolling tabs are strong (they are too buggy), then we should try the fixed-width tabs you describe above:

@Catrope and I just talked about this in person, so he has some additional thoughts.

You could try storing the page's Y scroll offset then immediately restoring it after the tab scroll.

In T223142#5273572, @Esanders wrote:

You could try storing the page's Y scroll offset then immediately restoring it after the tab scroll.

That could work. I wonder if the quick "down and up" would be visible.

Roan has come up with a proper implementation, which I think is a simplified version of Element.static.scrollIntoView. Feel free to have a look. It's currently Jenkins -1 on selenium and phan issues that don't seem related 😠

Change 518151 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/skins/MinervaNeue@master] Don't scroll vertically when scrolling active tab into view

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

Change 518857 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/skins/MinervaNeue@master] Improve tab scrolling logic

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

Change 518151 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Don't scroll vertically when scrolling active tab into view

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

Change 519241 had a related patch set uploaded (by Kosta Harlan; owner: Catrope):
[mediawiki/skins/MinervaNeue@wmf/1.34.0-wmf.10] Don't scroll vertically when scrolling active tab into view

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

Change 519241 abandoned by Kosta Harlan:
Don't scroll vertically when scrolling active tab into view

Reason:
will wait for wmf.11

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

@Catrope I've left a minor review comment on there and a +1, if you don't want to change anything I'll +2 it on Monday.

Change 518857 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Improve tab scrolling logic

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

The default view for the middle tab is as the following and it looks acceptable to me (I checked with a real device and browser emulators):

Thanks @Etonkovidova, looks good to me too.