Change 339479 had a related patch set uploaded (by Mooeypoo):
Style the 'old' RC option fieldset

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

https://gerrit.wikimedia.org/r/339479 answers #1 and #2

#3 -
I am going to raise a flag about #3 and involve @Catrope for an Engineering decision here. Making it delayed is technically possible, but makes me twitch. Do we really want this?

#4 - will be fixed soon.

#5 - The icon used is an OOUI icon using the default settings (1.875em size) -- @Pginer-WMF please approve whether you want me to force-override the OOUI default here or if this is just an unintended mismatch from the prototype?

Change 339540 had a related patch set uploaded (by Mooeypoo):
Stop mousedown propagation when capsule item 'x' button is clicked

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

https://gerrit.wikimedia.org/r/339540 answers #6.

Change 339572 had a related patch set uploaded (by Mooeypoo):
RCFilters UI: Fix CapsuleItemWidget popup styling

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

https://gerrit.wikimedia.org/r/339572 answers #4.

Regarding #7, @Volker_E mentioned that we shouldn't touch the design at the moment, since it's overriding OOUI styles that are being reconsidered for global UI standardization.
I defer this to @Volker_E and @Pginer-WMF

Please also note #5

The "Restore default filters" icon is bigger than expected. The icon in the prototype is 24x24 vs 26.25x26.25 in betalabs.

Icons in OOUI are set to 1.875em, which isn't really 24px. @Catrope mentioned that there's a bug open about that (I didn't find it) but I am not touching that one either until that is resolved or until either of you tell me otherwise to override this specifically for us.

To sum up:

(1) The "Recent changes options" label and line around the old filters should be removed and replaced by a simple divider (horizontal line) at the bottom of the whole group of filters, as illustrated in https://www.mediawiki.org/wiki/Edit_Review_Improvements#/media/File:Recent-changes-step1-initial.png

(2) Hovering a tag should show the "hand" (pointer) cursor. Currently the text cursor is shown instead. Look at the the current prototype

Fixed in https://gerrit.wikimedia.org/r/339479

(3) Tooltips for the tags should have a small delay. Currently they appear immediately.

Putting a halt on this for the moment; we can implement this but it won't be too pretty -- @Pginer-WMF, did you actually mean for this delay to happen, or is it just a byproduct of the way the prototype works?
Awaiting reply before I implement if needed.

(4) Tooltips currently have a disproportionate margin.
Note: The color of the font is also different

Fixed in https://gerrit.wikimedia.org/r/339572

(5) The "Restore default filters" icon is bigger than expected. The icon in the prototype is 24x24 vs 26.25x26.25 in betalabs.

This is an OOUI standardization issue.

(6) Removing a tag by clicking the "X" icon should not result on the search bar getting focus or the panel being opened. Currently the panel gets opened when removing a tag.

Fixed in https://gerrit.wikimedia.org/r/339540

(7) Greyed-out tags are not using the right colors. Background should be #EAECF0 and text #72777D. More details in https://phabricator.wikimedia.org/F4680134

This is an OOUI standardization issue.

Change 339572 merged by jenkins-bot:
RCFilters UI: Fix CapsuleItemWidget popup styling

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

Change 339540 merged by jenkins-bot:
RCFilters UI: Stop mousedown propagation when capsule item 'x' button is clicked

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

Change 339479 merged by jenkins-bot:
RCFilters UI: Style the 'old' RC option fieldset

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

#3 is resulted in OOjs UI sizing generally basing itself on VE's base font-size: 12.8px and on OOUIified HTMLForm's font-size: 14px, resulting in icons 26px size. It hurts, but that's our reality T97631 we currently have to live in.

In T158006#3051615, @Mooeypoo wrote:

(7) Greyed-out tags are not using the right colors. Background should be #EAECF0 and text #72777D. More details in https://phabricator.wikimedia.org/F4680134

This is an OOUI standardization issue.

Note that the greyed-out state is a specific state of Recent Changes, not a general "disabled state". In our case, the tag is not disabled (you can still click the X to remove it, or select it to check the filter and turn it into a highlight). It would be problematic to represent these tags as completely disabled. So it is not clear to me whether it should be part of the general tag component or part of out particular application.

In T158006#3050878, @Mooeypoo wrote:

#5 - The icon used is an OOUI icon using the default settings (1.875em size) -- @Pginer-WMF please approve whether you want me to force-override the OOUI default here or if this is just an unintended mismatch from the prototype?

The icons in the OOJS UI demo are 24px:

The main issue is that the icon looks too big for the text label next to it. It seems to be a problem with icons using inconsistent margins in their visual assets that makes this particular icon bigger than usual (I reported it as T158953).

Changing that particular icon could break other places where it is used, maybe @Volker_E has a better idea on where to adjust this without undesired side-effects.

In T158006#3051615, @Mooeypoo wrote:

(3) Tooltips for the tags should have a small delay. Currently they appear immediately.

Putting a halt on this for the moment; we can implement this but it won't be too pretty -- @Pginer-WMF, did you actually mean for this delay to happen, or is it just a byproduct of the way the prototype works?
Awaiting reply before I implement if needed.

The delay is intentional, and has a purpose. We want users to add and remove filters to be as fluent as possible. We also want them to have clarity on what filters do when that's not clear.
Tooltips appearing after a second aligns with those goals: you can operate the tags without additional info getting in the way causing distraction, but as soon as you wonder what a filter was doing you can hover i and get an answer. Manipulating tags is a recurring activity, while getting clarity on a filter is a "one time" action, and we don't want to tax users regular activities because of the "one time" situations.

In T158006#3051585, @Mooeypoo wrote:

Regarding #7, @Volker_E mentioned that we shouldn't touch the design at the moment, since it's overriding OOUI styles that are being reconsidered for global UI standardization.
I defer this to @Volker_E and @Pginer-WMF

As I mentioned above (T158006#3052612), we are not trying to redefine the "disabled" state. The disabled state should look as if you could not click the "x". The state we are defining is one specific for the Recent Changes page where the tag has no effect but is still operational (you can close it). Maybe that is useful to other contexts (and needs to be part of the standard tags) or not, but I don't think it should be used for the standard "disabled" state.

In T158006#3052663, @Pginer-WMF wrote:

The main issue is that the icon looks too big for the text label next to it. It seems to be a problem with icons using inconsistent margins in their visual assets that makes this particular icon bigger than usual (I reported it as T158953).

Changing that particular icon could break other places where it is used, maybe @Volker_E has a better idea on where to adjust this without undesired side-effects.

Yeah, @Catrope mentioned that there's a bug report about this. Apparently we seem to be using different sizing in oojs-ui in production?
Again, I don't mind overriding this sizing -- but if it's standard like this in ooui then (a) we should fix it there, and (b) I am concerned that it will be a bit of an "endless pit" of adjustments -- if I fix the trash icon, should I also fix the magnifying glass icon inside the input, and whatever other icons we use throughout? It could quickly become a bit of a nightmare.

Icons right now are 1.875ems and the difference in font size and line-height between the demo and production may be the cause of why the sizing is slightly different.

So if it's super important, I'll do it, but if it can wait for ooui-wide fix, it would be a lot better, and prevent us from overriding a bunch of stuff.

In T158006#3052686, @Pginer-WMF wrote:

The delay is intentional, and has a purpose. We want users to add and remove filters to be as fluent as possible. We also want them to have clarity on what filters do when that's not clear.
Tooltips appearing after a second aligns with those goals: you can operate the tags without additional info getting in the way causing distraction, but as soon as you wonder what a filter was doing you can hover i and get an answer. Manipulating tags is a recurring activity, while getting clarity on a filter is a "one time" action, and we don't want to tax users regular activities because of the "one time" situations.

Okay, fair enough, I wanted to verify. I opened a new task for that T158993: Create a delay when opening the RCFilters CapsuleItemWidget "description/conflict" popups since it's a separate issue, and we should track/prioritize it. (There are also separate small concerns to solve with it, like what happens if a user hovers over all popups -- we need to make sure the delay only opens the popup if the mouse is *still* on top of it, so it's not just a matter of "setTimeout", etc)

In T158006#3052711, @Pginer-WMF wrote:

As I mentioned above (T158006#3052612), we are not trying to redefine the "disabled" state. The disabled state should look as if you could not click the "x". The state we are defining is one specific for the Recent Changes page where the tag has no effect but is still operational (you can close it). Maybe that is useful to other contexts (and needs to be part of the standard tags) or not, but I don't think it should be used for the standard "disabled" state.

Good point. I was avoiding the styling of the capsule mostly because it just looks pretty significantly differently than what we currently get from ooui (even by the X icons) -- so in that case, while I can override the widget (to be an icon instead of an indicator, changing the 'x') it will require quite a large override of current OOUI styles.

However, you make a good point about the "mute" state, that isn't like a disabled state, and that part I can definitely implement.

@Pginer-WMF the only question here is -- if I just implement the colors of the 'muted' state, without touching the colors and styling of the "standard" capsule, would that still look good? Is a partial implementation okay for now, or should I do all-or-nothing (and if that's the case, which one do I go with? all, or nothing?)

Further investigating the icon issue, there is an old bug defining the problem: T11119: Improper base font size in monobook

As I suspected, the issue is conflicting font size. The problem is that if I want the icon to be 24px, I change the font size to be font-size: 0.8em (which also brings it "back" to the font size of the *interface* outside of mw-body-content) the text will now look super small.

Compare current font-size (with the icons being bigger than 24px):

To "new" font-size of 0.8em (with icons being 24px):

If we start changing individual icons sizing, the placement and positioning of those icons will also be affected (like the icon inside the capsule widgets, or inside button widgets or inside the inputs, which are mostly position:absolute; with alignment rules depending on their sizing.)

For example, my second attempt was to try and only change font-size on the icon itself, by adding

	.oo-ui-iconElement-icon {
		font-size: 0.8em !important;
	}

To the 'filter wrapper' widget.

This produced icons that are 24px, but it also screwed-up the placement of the icons (specifically the magnifying glass):

This should be fixed mw-wide and in OOUI.

Below is the summary of checked fixes for this task. Except for #4, there are no open questions/issues left.

QA recommendation: Product should weigh in.

DONE (1)

(1) The "Recent changes options" label and line around the old filters should be removed and replaced by a simple divider (horizontal line) at the bottom of the whole group of filters, as illustrated in https://www.mediawiki.org/wiki/Edit_Review_Improvements#/media/File:Recent-changes-step1-initial.png

DONE (2)

(2) Hovering a tag should show the "hand" (pointer) cursor. Currently the text cursor is shown instead. Look at the the current prototype

For (3) a separate task is filed: T158993: Create a delay when opening the RCFilters CapsuleItemWidget "description/conflict" popups

(3) Tooltips for the tags should have a small delay. Currently they appear immediately.

For (4) @Pginer-WMF please confirm that the current state of #4 is acceptable - the display of tooltips is different from the prototype. The margins do not quite adjust to the length of the text; the background is white. The background for tooltips in the prototype is grey which is consistent with other tooltips (.e.g. for the links such as 'Preferences' etc

(4) Tooltips currently have a disproportionate margin.
Note: The color of the font is also different

For (5) per @Mooeypoo: This should be fixed mw-wide and in OOUI.

(5) The "Restore default filters" icon is bigger than expected. The icon in the prototype is 24x24 vs 26.25x26.25 in betalabs.

DONE (6)

(6) Removing a tag by clicking the "X" icon should not result on the search bar getting focus or the panel being opened. Currently the panel gets opened when removing a tag.

For (7) per @Mooeypoo: This is an OOUI standardization issue.

(7) Greyed-out tags are not using the right colors. Background should be #EAECF0 and text #72777D. More details in https://phabricator.wikimedia.org/F4680134

In T158006#3053852, @Mooeypoo wrote:

Again, I don't mind overriding this sizing -- but if it's standard like this in ooui then (a) we should fix it there, and (b) I am concerned that it will be a bit of an "endless pit" of adjustments -- if I fix the trash icon, should I also fix the magnifying glass icon inside the input, and whatever other icons we use throughout? It could quickly become a bit of a nightmare.

I agree that a general fix in the UI library seems the right way to go.

@Pginer-WMF the only question here is -- if I just implement the colors of the 'muted' state, without touching the colors and styling of the "standard" capsule, would that still look good? Is a partial implementation okay for now, or should I do all-or-nothing (and if that's the case, which one do I go with? all, or nothing?)

If we can have the colors right, that is better than nothing. It would be great to support the colors for our specific case, and fix the general component (T158400), which would make tags better in different cases making our specific case as intended.

In T158006#3054617, @Etonkovidova wrote:

For (4) @Pginer-WMF please confirm that the current state of #4 is acceptable - the display of tooltips is different from the prototype. The margins do not quite adjust to the length of the text; the background is white. The background for tooltips in the prototype is grey which is consistent with other tooltips (.e.g. for the links such as 'Preferences' etc

(4) Tooltips currently have a disproportionate margin.
Note: The color of the font is also different

Tooltip size seems acceptable. It works well for text long enough to fill more than one line. It could be better for text shorter than one line where you can notice the tooltip does not adapt to the text size. However, while the initial status looked quite broken, the pending fixes now could be considered just a separate small improvement for future steps.

In T158006#3057212, @Pginer-WMF wrote:

Tooltip size seems acceptable. It works well for text long enough to fill more than one line. It could be better for text shorter than one line where you can notice the tooltip does not adapt to the text size. However, while the initial status looked quite broken, the pending fixes now could be considered just a separate small improvement for future steps.

Yeah, the popup widget doesn't change its width very easily - I've had a brief talk with @Volker_E about this, and I think it's something we should adjust in OOUI as well. Right now, adjusting the *width* to be dynamic is a pretty big nightmare, but it definitely shouldn't be, and the use-case that we have is more "tooltips" than "popups", so it's something we should definitely consider upstreaming.

If it's not too horrible for the moment, we should leave it as-is, but definitely try to prioritize something like this upstream for OOUI.