When looking at this task, it occurred to me that a lot of the features work to an acceptable degree on mobile (IMO).

Many of the layout bugs can be fixed through CSS and skin-specific overrides for Minerva.

Where the filters really fall down though, is the tag-selection dropdown.

1. The resizing behaviour causes the options-container to shrink to width=0 on mobile
2. The selection modal brings up the software keyboard, which severely limits the screen real estate.

When evaluating solutions to these problems, we talked about redoing the filters as native <selects> elements, or placing them in a MobileFrontend modal (per description), however I think we overlooked another solution, which is: fix the dropdown.

Fixing the dropdown would mean:

1. prevent the dropdown from shrinking to width=0
2. Not triggering the virtual keyboard when the dropdown is activated.

I think in this case, text input (and thus keyboard) is non-essential. As long as the dropdown items remain selectable, it still provides the necessary functionality of adding/removing filter tags/namespaces etc.

The shrinking behaviour is created by OOUI's setClippableElement() and setClippableContainer() on line#57 of MenuSelectWidget.js. Commenting out these two lines prevents the clipping behaviour, resulting in an almost useable widget (if not for the checkboxes triggering the virtual keyboard):

In T224655#5246908, @Jdrewniak wrote:

Where the filters really fall down though, is the tag-selection dropdown.

It seems like all three filters (basic, namespace, and tags) use the same dropdown panel thing and are equally broken?

In T224655#5246908, @Jdrewniak wrote:

I think we overlooked another solution, which is: fix the dropdown.

Good point. I think we made the assumption that fixing the filter menu but leaving it on the page wouldn't be a great experience. I think you're right in challenging that assumption. I added a quick mockup below. If we wanted to go that route I don't think we'd be able to support the search functionality (space is too tight and the search field not being fixed to the top of the screen makes things a bit hectic). The value of putting it in a modal is that there would be more space, and we could keep the search functionality.

@alexhollender, yes, all three filters use the same dropdown, and are thus equally broken :)

I think we made the assumption that fixing the filter menu but leaving it on the page wouldn't be a great experience

That's true. I might not be a great experience, but it might be an adequate experience. When compared to the native <select> element, the dropdown has the advantage of being more descriptive, organized into sections, and having a "highlight" feature. When compared to the overlay idea, in theory the dropdown retains all it's functionality with more available space, which is definitely a plus.

The downside of the overlay idea though, is that it would require us overriding a substantial amount of Mediawiki core behaviour for a solution that is mobileFrontend/Minerva specific. The MF Overlay code is buggy and error-prone, and if the core code were to ever change, it would likely break the MF/Minerva solution as well. In essence, making the functionality skin-specific is a high maintenance burden.

I've created T225499 and updated T223363 (that one could probably use more detail though) to reflect what I think are the two bigs chunks of work in this spike.

1. Make the filter dropdown work on mobile
2. Make the filters look good :)

With regards to making the dropdown work on mobile, I've found some easy solutions that fix some of the bugs (the menu options disappearing for example). The hardest part of T225499 I think is handling the virtual keyboard.

I think we should wait for that task to be completed before doing the visual changes in T223363. I haven't identified any unforeseen challenges with those style changes though, so I hopefully that task won't be too difficult.

@Jdrewniak cool, sounds like that might be the best direction. We don't need to support highlighting btw. By removing that button on each row there is more horizontal space for the description.

Looks like Web-Team-Backlog is working on this, so we are marking this external