Also, re #3, in some of the mockups they're on the left, and some on the right -- since we have more UI elements to include (pagination, on the right side for example) so I am actually not 100% sure where they should go right now. We could add them to the right side for the moment, but when we add pagination they will likely have to move - either to the left of the pagination controls (but still relatively to the right) or at the left of the interface.

We can get them to auto-close, but according to the design, both popups have more options in them (see T168513: Enable 'Group results by page' preference on the RC page itself) so they can't really be drop-down widgets when those are implemented (which is very soon).

The state is either on or off; if we only display it as "on" when something is selected, then a user will press that button over and over again with no result (the button will remain non-active because nothing is selected) until the user selects something, in which case the button will finally respond.

The filters are only excluded when they're selected, according to spec. We don't highlight excluded namespaces, because they're not there, so if the filter isn't selected and is just highlighted, it won't show the "not" message because it's highlighting the namespace itself. I wouldn't touch the active state of the button itself because that lets users choose the excluding namespaces even if none is YET selected.

I'll take a shower look at the rest of the questions, but regarding the free form input, if anyone fills in the URL (and when I implement listening to the preference of all act the same) with some number, that number is inserted in order to the most of current options. You can try that by changing days= parameter in the URL to slang custom. If you use fractions, like days=0.01 it will translate to hours and place them in order.

I assigned it tor @Catrope because he implemented most of the fixes that were needed; it came back due to the spacing of the items, which is actually a slight annoyance (because of the padding/margins and icon in there)

In T162784#3439402, @SBisson wrote:

In T162784#3318842, @Mooeypoo wrote:

So, @Catrope, technical question -- we should definitely respect the 'days' parameter on load, but do we actually need to use it in the system, or should we output 'from' with the proper timestamp for all time intervals (hours/days/month/etc) ?

days=5 and from=<5 days ago> are not the same. They are equivalent right now but one is relative while the other one is absolute. If I open a filter I've saved a week ago they don't mean the same thing anymore.

Of course you could save days in the filters and translate it to from every time you query but that seems unnecessary since the server supports days and could very easily support hours.

In T170214#3428606, @jmatazzoni wrote:

In T170214#3428591, @Mooeypoo wrote:

This is a bit of a radical suggestion, but we could try to do this part in the front end, and depend on sending the data on closing the menu.

Ingenious! Is there a way to also count Saved Filters with that, which, of course, don't require opening of the panel.

This is a bit of a radical suggestion, but we could try to do this part in the front end, and depend on sending the data on closing the menu.

Abandoned the RCFilter-specific fix since this got into the OOUI release today. Should be available on Beta later today.

In T170190#3422783, @Catrope wrote:

In T170190#3422558, @Mooeypoo wrote:

I don't see this in Chrome or Firefox on ubuntu. What browser did you see this in?

Note that per the bug report, this only happens in non-enhanced mode. You don't need to change your prefs to disable/enable enhanced mode, you can just use ?enhanced=0.

In T170190#3422803, @jmatazzoni wrote:

Actually, also in Safari.

Second issue: do you see the misaligned Talk tag in this screenshot? Has that been reported?

I don't see this in Chrome or Firefox on ubuntu. What browser did you see this in?

The above fix is for the message. I'm still trying to verify where to set up the new default for expansion, that fix will come soon.

In T168043#3401249, @jmatazzoni wrote:

There's something about this that I've been uncomfortable with, and now that I see the implementation on beta the penny dropped as to what it is. Actually, there are a couple of things;

Making the legend collapsed by default: Did this, in fact, happen? If so, I don't understand the thinking behind it. It is impossible for new users to intuit the meaning of the various symbols in the legend. So if users get this page with the legend collapsed, we are making it that much harder for them to ever learn the meaning. Don't we want them to learn, and have a better understanding of the results? I suggest the box be open by default.

Using the word "Legend" by itself: In its collapsed state, the simple word "Legend" is not very explanatory as to what this is. Obviously, this problem is more severe if we make the box closed by default. But even without that, I think we can improve this. Typically, one has a 'legend" of a map or chart of some kind. Thus, to begin with, this term is not a common thing on search results. And then there's the fact that in its collapsed state it's quite small and insignificant looking. Given the width of the box here, we have some room to expatiate. So I suggest a more descriptive title. Here are some name suggestions. See if any of these work for you:

• Legend of abbreviations
• Abbreviations defined
• Abbreviations used on this page

In T168043#3415898, @jmatazzoni wrote:

@Mooeypoo, I see you claimed this task and that there is a Patch for Review. But it was still in Product Design, so changes were still being made to the spec.

It's now in RFP. Please review the rewritten description, above. In particular, note the change of title and the fact that the default state will be open, not closed.

As @matmarex points out, there already is a ticket to split out legacy modules to non-legacy ones. It seems to not be high priority, but this behavior in RTL/LTR mixes in mobile makes at least that part a priority itself. see T89981: Split the mediawiki.legacy.shared module into non-legacy manageable parts for context.

@Volker_E I have added a proposal patch for this, making language a new module and setting it as a dependency of mediawiki.skinning.content.

@Catrope and I checked into this, and the definition is in the mediawiki.legacy.shared module. Two conclusions strike me as action items:

Fixing the icon size will be a bit of an issue, since that's the icon that is in OOUI, but I'll give it a try. The padding is also consistent through ooui menus, but we have a lot more leeway with it, providing the icons are not blocking a portion of it (ooui icons have whitespace around them, it's a known issue, but one that prevents us from using exact size measurements of the actual icon rather than the whole whitespace-plus-icon box, which is what the svg itself is using.

Oy, sorry, when we changed the way validation works, I removed the condition to treat spaces as empty.
Fixed in the commit above.

This shouldn't happen anymore, can you re-check? The "Apply" button should be disabled when the text is empty, and the saved query shouldn't be saved at all if there's nothing in the input, including when you press enter.

Fixed the tooltips.

Whoops. Sorry about that.

@Pginer-WMF question that will affect implementation: What happens if there are no results? Can we not show the legend in such a case.

Just to verify something -- those two lines may actually have something left in there from external extensions. For example, I'm a bit confused about where "Translations" went in your second set of screenshots... it should still remain, since we did not yet implement it in RCFilters.

Gadget is officially available on mw.org: https://www.mediawiki.org/wiki/MediaWiki:Gadget-NotifCountTitle.js

In T75209#3277815, @Framawiki wrote:

Script alone: https://fr.wikipedia.org/wiki/Utilisateur:Framawiki/js/addNotificationCounterToDocumentTitle.js
It seems to work well, what is the next steep ?

@Nirmos I am not 100% sure where you're going with this, but in an effort to help, I created a quick and dirty gadget for you to use as a basis for whatever you need. I did end up loading mw.echo.api module, for convenience, and the required i18n message.

In T168387#3366186, @Mattflaschen-WMF wrote:

In T168387#3365100, @Mooeypoo wrote:

• Do we have a set range of options to choose from, or a free-text number with days?

Don't see a reason to limit to a fixed set of options, unless that's required for performance reasons. We may want to validate that it's an integer (not 1.5 days), depending on how often the cron job runs (though if it's general infrastructure, it will probably run often enough that we don't have to).

In T168570#3368942, @Nirmos wrote:

I know it is complicated right now and that's exactly what this task is about: creating and exposing an easy-to-use function so that gadget authors don't have to "inject those numbers into the html of the badges".

Opening them updates them already, so I assume you mean you want to update their counters?

What use case are you thinking about? The Special:Notifications page? The badges? They already both have a way of updating themselves, why would you need a function? Is there a specific gadget you're thinking about that needs to use it specifically?

A couple of questions we should ask to prepare for this:

The new size is only implemented on the RCFilters section, and not the results list. The results list will continue to have the same size as the nojs version (font size of the content container)

Implemented everything except for the message footer for namespaces and tagged edits -- after a chat with @jmatazzoni, my understanding that the extra explanation in the footer in the example above is only relevant to "Users" and "Categories" which are lookup elements, and not to Namespaces and Tagged Edits.

In T166626#3354970, @TBolliger wrote:

With the new GUI, the "Add one username per row." sentence is no longer needed.

Didn't implement the (?) button yet because I don't have a link to go to -- we can add that later.
Other than that, all functionality should be there.

@Pginer-WMF quick question -- we already have a footer in the menu right now for sending feedback about the RCFilters beta. Where do I put this footer now? Under the footers above (the text one for the tag/namespace and the button selection one for the default view) ?

In T167384#3346666, @jmatazzoni wrote:

@Mooeypoo, please note the most recent interchange between Pau and me, above, re. adapting his design for just the two Advanced menus we'll be launching at first. Basically, to cut to the chase, it's in this screenshot.

This was an issue with all options that are "outside" the RCFilters dropdown. Fixed in the commit above, and will be thoroughly fixed in an upcoming commit to rewrite (and unit test!) the way we do and compare URLs.