It seems to me like the "ideal" would be for markup & components to be the same regardless of skins, and then skin-specific styles might override. If that's not feasible, and (especially) if this is a situation that will come up again and again, then yeah maybe exposing some CSS-only Button styles as a mixin may be worth introducing.

If there is only a single situation where it comes up though, it might be better to see if we can reconsider the design.

Change 958581 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] History: Do not use MediaWiki UI for button styling

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

Change 958582 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] PagerTools: Use codex buttons when configured for tools

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

Change 958583 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Thanks@master] Thanks should use preferred classes for thanks link

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

@egardner https://gerrit.wikimedia.org/r/958582 should allow us to do away with the mixin and vary the HTML based on skin. We have been using skin options to vary HTML in other ways so this seems consistent with other elements.

The Thanks follow up patch (https://gerrit.wikimedia.org/r/958583) makes use of the new hook parameter.

Those 2 patches should unblock web team from getting rid of the mixin in the history page.

Could DST review the approach within the next month and let me know if you see any problems with this proposed path forward (or suggest alternative approaches?)
Thanks in advance.

Change 958989 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Stop using mediawiki ui mixin for history page

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

Change 958581 merged by jenkins-bot:

[mediawiki/core@master] History: Do not use MediaWiki UI for button styling

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

Change 958583 abandoned by Jdlrobson:

[mediawiki/extensions/Thanks@master] Thanks should use Codex classes for thanks link on Minerva

Reason:

Current thinking is that we probably want Minerva and Vector skins to be consistent here, so abandoning for now until further discussion.

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

Change 958582 abandoned by Jdlrobson:

[mediawiki/core@master] PagerTools: Use Codex buttons when configured for tools

Reason:

Current thinking is that we probably want Minerva and Vector skins to be consistent here, so abandoning for now until further discussion.

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

In T345768#9258760, @Jdlrobson wrote:

We talked about this today with the design systems team. We feel:

1. The undo and thanks here does not fit into the definition of a "button"
2. From a technical point of view it doesn't make sense to style interface elements differently depending on skin.

I would thus propose removing the styling on the mobile site.
@JScherer-WMF would you or the designers have any concerns about doing that?

Hi @Jdlrobson These count as buttons because they are calls to action on a specific edit. The bigger buttons in Minerva are much more accessible than the Vector styles, which would be extremely difficult to tap with one's fingers. That being said, the Minerva design has other buttons styled as hyperlinks which aren't accessible because the tap targets are too small. I don't think we should make this page less accessible for consistency's sake.

@nayoub and the editing team have a better sense of the use case for this page. Nico, do you mind weighing in on Jon's proposal above?

The bigger buttons in Minerva are much more accessible than the Vector styles, which would be extremely difficult to tap with one's fingers

If we are concerned about tapping, surely these should also apply on Vector 2022 for users on touch devices?

Note: We could also increase the touch areas without styling them as buttons by adding some padding to the link.

That being said, the Minerva design has other buttons styled as hyperlinks which aren't accessible because the tap targets are too small.

Correct.

I don't think we should make this page less accessible for consistency's sake.

This is not so much about consistency. The mechanism Minerva uses to turn these into buttons will no longer be supported. If we do nothing they will no longer be buttons. If we want to retain them as buttons we need to do some work here and think about them holistically (e.g. if they are buttons in Minerva they will need to be buttons in Vector too as the two pages share the same HTML).

Change 958583 restored by Jdlrobson:

[mediawiki/extensions/Thanks@master] Thanks should use Codex classes for thanks link on Minerva

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

Hi @Jdlrobson & @JScherer-WMF (thanks for the ping!), I’d be curious to learn more about the historical context of the Minerva talk page design – assuming the buttons were designed purposefully, whether for increased accessibility (tap targets) or other reasons. Therefore, I’d lean towards keeping them – and eventually, potentially reconsider the design on Vector to map to this as well.
Similar to how the “reply” tool came to exist as a button, it’d be interesting to see how this page UX could be enhanced in the future.
Regarding the definition of the buttons, I’d assume these fit since they perform actions (thanking the editor, undoing the edit) unlike the others which are links (transporting you to the user’s talk page, diff, etc).

Regarding the definition of the buttons, I’d assume these fit since they perform actions (thanking the editor, undoing the edit) unlike the others which are links (transporting you to the user’s talk page, diff, etc).

While this is true for the thanks button, the undo link is just a link to the editor which navigates away from the page. It's a poor experience. @Swal

I’d be curious to learn more about the historical context of the Minerva talk page design – assuming the buttons were designed purposefully, whether for increased accessibility (tap targets) or other reasons.

@nayoub in terms of why the design was chosen, there seems little documentation of the decision on T219895 unfortunately. Although confusingly there isa bullet point saying we should 'remove button-y styles from "Undo" button' and T216420 even considered hiding the button altogether due to the poor experience.

Therefore, I’d lean towards keeping them – and eventually, potentially reconsider the design on Vector to map to this as well.

Given the technical changes we currently have 3 options

1. switch both skins to buttons (a trivial change)
2. switch both skins to links (a trivial change)
3. support different versions in different skins (a larger change that requires a dedicated team).

FWIW I was leaning towards the trivial changes of reducing undo to a link rather than the harder/larger change:

1 ) this page is seldom used on mobile - to access it uses must visit the settings page on mobile and opt into the advanced mode - most users of the history page do not see undo links - and see a completely different page for viewing history e.g. https://en.m.wikipedia.org/wiki/Special:History/Masaki_Yamamoto
1b) The users who have requested the page are telling us they prefer the "desktop" versions of pages.

2. We have a history of editors complaining about any changes to the desktop history page. It seems most power editors prefer information density.

Note undo/thanks buttons on the history page would reduce the number of rows (see screenshots)

3. Lack of ownership for history page component.

If the editing team or another team are happy to explore option #3 then the lack of ownership is a moot point.

My initial reaction is that Jon is right regarding desktop - changing Undo/Thank to buttons is going to require additional community discussion/buy-in due to the (minor) decrease in information density.

I don't love the idea of changing these buttons to links in mobile for the same reasons @JScherer-WMF noted above - they're just much harder to tap, but if we need to make a change this seems to be the less disruptive option.

What if undo was not a button but we kept the touch area?

Thanks for all your responses @Jdlrobson, I agree with you and @Samwalton9-WMF on your points.

Given all the constraints associated with the different changes, I agree it seems more reasonable for the time being to change the buttons to links but keep the touch area – to preserve the accessibility of the current mobile UX as noted by @JScherer-WMF.

Change 958583 merged by jenkins-bot:

[mediawiki/extensions/Thanks@master] Minerva: Thanks should use Codex classes for thanks link

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

Change 958989 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Stop using mediawiki.ui mixin for history page

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

This is now addressed.
{F39971884}
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Spain&action=history&useskin=minerva

Note most people will continue to see this:
https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=Special:History/Spain (view in an incognito window)