We're using the icons oojs ui is using... if they are too small we'll need to change them in oojs ui too..

We just specify these .slider-button icons to be at a larger size in css, no?

No.. :(
We use a standard icon size for all things that identify themselves as icons. So we either reduce the whitespace in the existing icon in oojs ui or use a new icon.

@violetto, technically we can, yes. SVGs are scalable so there is no problem there.
@Jdlrobson, while I can understand that you don't want a local override, but just specifying a larger font-size in the container element should update the size of all OOjs UI elements. Is that doable?

Changing font-size has other side effects.

The position of an icon within the 24 x 24px canvas is specific to its form, relative to other icons within the set. To maintain their relative proportions with other icons, the canvas has to be consistently sized. If we decide to change the canvas for one icon, others who are using the same icon in other context might experience misalignment like that:

I also imagine if someone is using these icons within a set width, this icon will not behave the same as the rest.

This is not impacting overlays too

I'm losing a lot of confidence in the oojs-ui icons.
I would suggest renaming our close and arrow icon glyphs for the time being to avoid this unpleasant clash.

So the css regression there is caused by T112571 - I'm suspecting someone made a change and didn't think about mobile. Can I suggest one we find the culprit we have a conversation around the current situation of icons - maybe in one of the frontend standard group meetings?

Sounds like Notifications which was loading OOjs UI server-side on all pages for a while until it was reverted today.

@matmarex I think so but even post revert we're still seeing problems... I've purged pages and still problem.

Increase size of left and right arrows so that they are more visible and tappable.

What are the desired sizes in px?

Currently, both icons are sized at 56x24px including the tappable area. The arrows look smaller because the SVGs have padding around the icons. Should we remove the padding, the arrows will look similar to the close icon.

We should have a chat about this before implementing anything preferably in a hangout to avoid confusion. The padding prevents scaling svgs and I'd personally like to revisit it...

@Jdlrobson @bmansurov @matmarex From my current estimation, we (as front-end devs) all agree that the white-space (as long as it's not there for spacing/sizing the icon relatively to the others) leads to unpredictable results when integrated in front-end code across different products.
We should – that was mentioned above – therefore get rid of surrounding whitespace in the SVGs where applicable, give guidelines about the relative position of the icon either towards the surrounding box, as in a button or towards text (starting point: text-bottom, baseline, text-top etc.; vertical alignment etc.) and leave it up to the developer to ensure the correct sizing.

Do we all agree?

Including the recommended whitespace in the icon makes it easier to use standalone. But you have a good point that it makes it harder to mix icons from different sources with different dimensions. We've had this problem in OOjs UI itself too when it was extended with the "WikiFont" icons (which generally had smaller built-in margins than previous icons).

I don't have a strong opinion, but I think it would be okay. @TrevorParscal and @Esanders authored most of the original OOjs UI icons, and @violetto authored most of the new ones.

Having variable sized icons would probably make our lives much much harder. It would be much easier to just fix these edge cases manually.

The inner padding of the icons is tackled in T177432 and will be updated when we set the icons overhaul in place. And no, we won't have variable sized icons across products. We will have one icon and scale this if necessary as we currently don't have a outspoken use case for, let's say, 300x300 px icons.
The reason for the original issue has nothing to do with OOUI (any more; removing tag), now it's the usage of a certain class (mw-ui-icon-small) in MinervaNeue on the MMV treatment that wasn't designed to be there.

Honestly, the MMV overlay has a few UX shortcomings (like there's no swiping). Leaving it up to the team to decide if this should be merged or the task declined – the icons are small, but the clickable area is big and provide fine usability. We could instead of small patching think about seriously improving mobile MMV overlay.

Change 398185 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/MobileFrontend@master] Don't make small slider icons on MMV overlay

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

Change 398185 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Don't make small slider icons on MMV overlay

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