Shahyar, thanks for noticing the details. Now I've seen the ragged spacing of Cancel [ Preview ] [ Reply ] it can't be unseen!
TL;DR : 1. I think having consistent bordered buttons in a form is worthwhile, and mw-ui-sleeper for the secondary ones is a good solution to avoid the multi-colored Skittles problem. 2. We should be able to apply the coloring behavior on hover & click of constructive/destructive/progressive/neutral to any text, including Reply * Edit * Thank. 3. What about your mw-ui-thin for the button in the topic titlebar ? Talking about these things is hard because we're imagining what button states will be and how they'll combine. It would be great if you could build a new Living Style Guide with many example buttons and text explaining the CSS usage. Change mediawiki.ui in core, cd resources , type make kss. On Tue, Mar 25, 2014 at 3:43 PM, Shahyar Ghobadpour < [email protected]> wrote: > 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. > (There is another approach, which is to draw a border around mw-ui-quiet buttons like Cancel upon hover and click. "Why is this alignment ugly? Oh,it's a button." I'm not crazy about that solution.) > > > - > * 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. > > OK, but then we do hide buttons with Reply * Edit * Thanks . I think the current mix of borderless and bordered in Cancel [ Preview ] [Reply] can be defended, though I prefer your approach. > > - > * Solution: *I've since changed [ Reply * Edit * Thanks ] to simple > anchors with no special classes. > > Noooo. These should have the constructive/progressive/destructive coloring that mw-ui-quiet buttons get on hover and click. Try it at http://tools.wmflabs.org/styleguide/desktop/section-2.html . Button colors communicate meaning, they're not just some arbitrary Agora color palette, we need to use them. A simple anchor with underline has problems for me because I right-click on anchors to copy URLs, to open in new tabs and windows, etc. So I think mw-ui-constructive/progressive/destructive and mw-ui-neutral should be decoupled from mw-ui-button's border and padding, so that you can apply them anywhere to get the state highlighting. > > In fact, I'm advocating that we remove [mw-ui-quiet] 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/ > (Note: click in a textarea to see the buttons appear, and enter something to see them activate.) I like it. Your mockup also introduces a mw-ui-thin [Reply] inside the topic titlebar. When would people use that instead of your inline Reply button or a full button? Is it a Flow-only design? -- =S Page Features engineer
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
