We'll take a look at this next sprint. If we can make a change upstream to either Codex or OOUI, we'll revert the override in Vector.

@Esanders @dchan I'd like to update the Codex link mixin (which gets applied by Vector and inadvertently targets OOUI link-buttons) to exlcude any elements with [role="button"].

This would be is a straightforward change we could make upstream, and it also aligns with the general intent behind these styles (the Codex link mixin is intended for text links, not for links styled as buttons). It would also encourage good accessibility practices.

How does this sound to you all? It looks like the VE toolbars are already applying this attribute.

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

[design/codex@main] Link: Exclude [role="button"]

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

I think that sounds reasonable. I'm sure there are gadgets out there without this attribute but at least we can offer an easy fix.

I like the attribute selector solution, but would recommend we add it in Vector (and Minerva if applicable) where the mixin is applied rather than in the mixin itself. The additional specificity—the equivalent of adding a class—is not ideal, so I think we should only add it where it is needed: inside MediaWiki where there are many anchor elements styled as buttons. We don't recommend styling links as buttons, so I don't think it's worth the additional specificity to account for it in the mixin, which could be used outside of Vector/MW.

In T373989#10154171, @AnneT wrote:

I like the attribute selector solution, but would recommend we add it in Vector (and Minerva if applicable) where the mixin is applied rather than in the mixin itself. The additional specificity—the equivalent of adding a class—is not ideal, so I think we should only add it where it is needed: inside MediaWiki where there are many anchor elements styled as buttons. We don't recommend styling links as buttons, so I don't think it's worth the additional specificity to account for it in the mixin, which could be used outside of Vector/MW.

@Jdlrobson what do you think about limiting the application of the Codex link mixins on the Vector/Minerva side instead of doing it upstream? If you open a patch to this effect I will abandon the Codex one.

I've moved this to blocked because there is some uncertainty of whether this should be applied at the skin level or within Codex itself.

moved to T375918

DST no longer things this change should happen in Codex, but should instead be resolved at the skin level. Next steps for this task are to add documentation to the link mixin in Codex that specifies best practices for applying it with "link buttons" and to propose changes to the skin in line with those best practices.

Change #1073313 abandoned by Eric Gardner:

[design/codex@main] Link: Exclude [role="button"]

Reason:

Abandoning this change – my recommendation is to apply this change at the skin level

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

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

[mediawiki/skins/Vector@master] Links: Exclude role="button" from link mixin styles

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

Change #1076850 abandoned by Eric Gardner:

[mediawiki/skins/Vector@master] Links: Exclude role="button" from link mixin styles

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

I think the conclusion here is that we don't recommend the Codex link styles should be applied to all a elements in a blanket fashion in an environment like MediaWiki, where there are lots of other a elements which need to look and behave differently. These styles are intended for text links, not for buttons/menu items /etc. We provide the Link styles as a mixin to allow users to specify custom selectors in order to avoid these collisions.

If using not pseudo-classes is not ideal due to specificity changes, then link styles should be scoped to mw-content or parser output somehow. But we're not going to change the Codex mixin upstream, because we want Codex to remain MW agnostic.

@egardner +1

then link styles should be scoped to mw-content or parser output somehow

content-embedded UI components complicate this a bit, but scoping to parser output will limit the side effects to a smaller subset of features.

In T373989#10195526, @Esanders wrote:

@egardner +1

then link styles should be scoped to mw-content or parser output somehow

content-embedded UI components complicate this a bit, but scoping to parser output will limit the side effects to a smaller subset of features.

We are currently working out how best to do this in Minerva based on bugs we've uncovered using cdx-link - there we used mw-body-content with problems, so I suggest we copy the approach there when we have settled on something. @Jdrewniak is currently leading this discussion in web team if you want to sync with him!

Just to check: Is this for mobile or desktop site or both? (bit confused - but I think this is just about buttons in VisualEditor on desktop and the description could be clearer)

It's just desktop. The icon-only button for publish on mobile uses a different tool type which isn't based on a link element.

Change #1082084 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[mediawiki/skins/Vector@master] Align Vector link styles with Minerva

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

Change #1082084 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Align Vector link styles with Minerva

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

This change causes link-buttons like (thank) on RecentChanges to use old (pre-July 2022) link color and do not adapt to the dark mode, example (from testwiki RecentChanges) below. This is not particularly visible in light mode (only if you know, you'll spot that).

Similarly, on a history page, selection modifiers ("All", "None", "Invert") above and below the list are affected (eg. on https://test.wikipedia.org/w/index.php?title=User:Asked42/sandbox1&curid=158659&action=history).

I haven't found other links that would behave the same way -- for instance "undo" is displayed fine

Thanks for the report -> T378771

Test Result - PROD

Status: ✅ PASS
Environment: PROD
OS: macOS 15.0
Browser: Chrome 130
Device: MBA
Emulated Device: NA

Test Artifact(s):

https://en.wikipedia.org/w/index.php?title=Hooded_skunk&veaction=edit

Test Case 1: Verify link buttons in toolbars do not have a border radius

1. Go to a page using the Codex link mixin.
2. Check link buttons in an OOUI toolbar.
3. ✅ AC1: Confirm that link buttons in toolbars do not have a border radius applied.