Page MenuHomePhabricator

Fix "Tags" padding to have it less close to the edge
Closed, ResolvedPublic

Description

(Copied from {192210} by @Jack_who_built_the_house,to split it in to actionable tasks.)

"Tags" link is too close to the right border, it's unbalanced with the left margin.

"Namespace" link icon's margin created by left icon's

.oo-ui-buttonElement-frameless.oo-ui-iconElement > .oo-ui-buttonElement-button > .oo-ui-iconElement-icon {
    left: 0.35714286em;
}

so, I don't know, maybe add

padding-right: 0.35714286em;

to &-widget.oo-ui-widget @ mw.rcfilters.ui.FilterTagMultiselectWidget.less? Then it will be

Event Timeline

Change 441229 had a related patch set uploaded (by Hagar Shilo; owner: Hagar Shilo):
[mediawiki/core@master] Fix "Tags" padding to have it less close to the edge

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

Mooeypoo added subscribers: Volker_E, Mooeypoo.EditedJun 20 2018, 11:21 PM

While we fix this specifically for RCFilters, I think this shows a discrepancy we have in OOUI as well.

So, heads up for @Volker_E here; It seems that in OOUI the widget displays with proper margins at the right side (https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#ButtonGroupWidget-destructive-icon-and-progressive-text)

In OOUI widget, the label has a padding all around it, which makes it behave like we want. In RCFilters, the label's "padding-right" is being overridden with this:

.oo-ui-buttonElement-frameless.oo-ui-labelElement > .oo-ui-buttonElement-button {
   padding: 0.57142857em 0.14285714em 0.5em;
}

So it seems like frameless buttons inside a ButtonSelectWidget don't have full padding around them. Is this known, and is that what we want? I think it makes sense that if a frameless button is inside a ButtonSelectWidget then its paddings -- right as well as left -- are the same as if the button was framed.

I know there's not a lot of usage so far for a frameless button set inside a ButtonSelectWidget, but I dont think we'll be the only ones using it, and if it is allowed (which it is) then it should be supported to look like a proper group, which right now it doesn't.

Thoughts, @Volker_E ?

@Mooeypoo Thanks for raising this. From a UI library perspective I don't see this as a general use case. The sense behind a ButtonSelectWidget is IMO to visualize that you can choose 1 out of n options and you get visual/aural feedback about it.
In the case of RCFilters it's not visible for the user that this is a ButtonSelect nor does it have to necessarily be exposed. Internally it might be preferable for simpler handling. Therefore I'd be against adding code on library side for ButtonSelectWidgets with frameless buttons. It speaks against the UX concept of a ButtonSelectWidget.

Change 441229 merged by jenkins-bot:
[mediawiki/core@master] Fix 'Tags' padding to keep it farther from the edge and document the source of the new right padding value

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

@Mooeypoo Thanks for raising this. From a UI library perspective I don't see this as a general use case. The sense behind a ButtonSelectWidget is IMO to visualize that you can choose 1 out of n options and you get visual/aural feedback about it.
In the case of RCFilters it's not visible for the user that this is a ButtonSelect nor does it have to necessarily be exposed. Internally it might be preferable for simpler handling. Therefore I'd be against adding code on library side for ButtonSelectWidgets with frameless buttons. It speaks against the UX concept of a ButtonSelectWidget.

OK, fair enough. This is a fairly unique (and somewhat mangled?) version of the ButtonSelectWidget...

Etonkovidova closed this task as Resolved.Jul 5 2018, 10:09 PM
Etonkovidova added a subscriber: Etonkovidova.

Checked in betalabs -

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 5 2018, 10:09 PM