Page MenuHomePhabricator

Support <div class="mw-ui-button><a></div> (or <span><a></span>, etc.) and update documentation about its usage
Closed, DeclinedPublic

Description

If you add class="mw-ui-button" to <a href="#">Some link</a>, the mediawiki.ui classes style it as an Agora button (good), but if you've visited the link the text retains the blue #0b0080 a:visited color from commonElements.css, and while you mouse-down on the link the text gets the yellow #faa700 a:active color. I don't think this is intentional, the dark gray #4a4a4a color from mw-ui-button should apply all the time.

If you add one of the "coloring" classes mw-ui-{primary/constructive/destructive} the text color remains in all states, which is why we haven't noticed this bug before. I think it's a CSS specificity issue, since none of these classes override the color for visited and active.


Version: unspecified
Severity: normal

Details

Reference
bz48184

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:16 AM
bzimport set Reference to bz48184.
bzimport added a subscriber: Unknown Object (MLST).

Two places where this happens:

  1. Log in to a wiki then visit Special:UserLogin. The [Create another account] button is just mw-ui-button, i.e. neutral.
  1. On https://en.wikipedia.org/wiki/Template:Clickable_button in its [Main page talk page] example that has a link.

The text should stay dark gray, see "Neutral button styling" in http://tools.wmflabs.org/styleguide/desktop/section-2.html

The fix may be to have add a more specific selector for a:active and a:visited styling in resources/mediawiki.ui, maybe in mixins/effects.less. I think the mw-ui-quiet variation is OK.

This is still reproducible for me. Just go to https://en.wikipedia.org/wiki/Template:Clickable_button and click "Main page talk page", then go back and (if needed) reload.

It will be purple in Vector.

Oh I see...
Should it be used in this way..? This is what mw-ui-anchor is for?

<a class="mw-ui-anchor mw-ui-constructive">test me</a>

Isn't that a limitation of wikitext markup that you can't add custom classes to links? I think that is the issue here.. we shouldn't be encouraging sub optimal markup such as
<div class="mw-ui-button>
<a>
</div>
in my opinion..

<a class="mw-ui-button"></a> should be the only way to use it.
The link is not a button by being inside a button element.

(In reply to Jon from comment #3)

Oh I see...
Should it be used in this way..? This is what mw-ui-anchor is for?

<a class="mw-ui-anchor mw-ui-constructive">test me</a>

That is not a button, it's just a colored anchor.

Isn't that a limitation of wikitext markup that you can't add custom classes
to links? I think that is the issue here.. we shouldn't be encouraging sub
optimal markup such as
<div class="mw-ui-button>
<a>
</div>
in my opinion..

<a class="mw-ui-button"></a> should be the only way to use it.

I disagree.

We should encourage the most concise markup for a button that works in wikitext.

Remember, this use case is the *only* reason (https://gerrit.wikimedia.org/r/#/c/114085/) mediawiki.ui.button is added by default.

Anything else (extension, gadget, user script) can use addModuleStyles (as needed, rather than global as it is now) or mw.loader.using.

If it can be used in this way, please update the documentation.
The documentation is like a contract. It's the only way we can ensure we support these sorts of use cases :)

  • Bug 61886 has been marked as a duplicate of this bug. ***

This doesn't block using mw.ui.button on more interfaces (forms, special pages, etc.), since they normally won't use this technique. Thus, removing that blocker.

It's already deployed for on-wiki content, which is what this bug affects.

Also, the on-wiki template uses span, so putting that for now. If there's some reason we should only allow div, we can still do that if needed.

Shall we decline this @Mattflaschen - we should be putting mediawiki ui in maintenance mode now?

Mattflaschen-WMF claimed this task.

Yes, I think so. However, we should think about how OOJS-PHP could maybe relate to on-wiki (user-controlled) content.