Hey everyone,

There's no list for this, so I am assuming that if you've been invited to a MediaWiki UI Hack Day, then you are interested, so you've been CCed. In addition, the Design list is on this, so, please make sure to reply all.

Our team (Core Features) has been implementing MW UI as the basis of our design with the new Flow extension. I think we're the first team to really do that to this extent, and so I have some preliminary feedback to give regarding this.

Design mockups have frequently called for the use of the "mw-ui-quiet" class. Unfortunately, we've been running into problems with it. Often, the use case is one of two scenarios:

1. In a form, next to a regular mw-ui-button.
2. Outside of a form, as a link with hover/focus context color.

Both of these scenarios have presented us with a serious problem: having a content element with padding, but no discernible borders, makes aligning these buttons impossible semantically. You are essentially forced to override mw-ui-quiet CSS locally to have no padding for it to look "normal", and then in that case, they are no longer button-like, but are instead simple links.

Problems:

• Exhibit A - in a form: note the excessive whitespace between the Cancel button and the others. Increasing the margin between buttons only makes matters worse, and causes the button to look even further away than intended.
  
  Solution: We are now using a bordered-button for all form buttons in Flow. We shouldn't be trying to hide buttons from the end user.
  
  
  
  
  
• Exhibit B - independent links: they do not align to edges, and they cannot match up to other inline-block or inline elements (we also lack a mw-ui-spacer or such class to apply to other elements so that they may inherit its padding and simulate it to even things out).
  
  Originally, we were using a CSS override to 0 the padding, but we shouldn't have to do that for mw-ui elements in core if we want to maintain a coherent style moving forward.
  
  Solution: I've since changed these to simple anchors with no special classes.
  
  

Given these issues, I can't see any real semantic usage for mw-ui-quiet. Can anyone give me a current usage that necessitates keeping it around?

In fact, I'm advocating that we remove it entirely from core, and instead use a different quiet button that is somewhere between the current quiet and the current regular buttons. I've been calling them "mw-ui-sleeper" for now. Here is an example of it in action (on topic Reply, Preview, and Cancel). http://area51.yar.gs/wmf/flow1/

Thoughts and concerns?

Thanks,

Shahyar

_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design