And I was unable to close the labels menu on my Phone after adding more than 12 labels.

Could you please explain that a bit more in-depth in order to understand the problem?

Regardless, some kind of media queries should definitely be involved here. Otherwise you get something like this, where it would fit on the screen if it weren't for max-height thing. (That's with what seemed like a more reasonable value, like 75 or 80.)

This is the issue:

True … feel free to change 60% to another value … it seemed about right for the labels dropdown … there 60% menu and 40% article seemed right

OK, I think I understand the issue now. That means the CSS properties that needs adjusting would be these here:

I'd just get rid of position: fixed, personally.

i'd be fine with removing the position: fixed;
but then there is still the issue that if you scroll down the long list of labels you have to scroll up again to get back to the article …

oh and for whatever reason … adding overflow to the css removes the white triangle from the top in the desktop version of the dropdown-menu

and why is there a hidden, unused close button in the dropdown menu?

but then there is still the issue that if you scroll down the long list of labels you have to scroll up again to get back to the article …

You could add an overflow-y: scroll of some sort I suppose, but it should surely be inside that media query. :-)

oh and for whatever reason … adding overflow to the css removes the white triangle from the top in the desktop version of the dropdown-menu

To me that's the least of the horrors of applying that style outside of the confines of the problem you were trying to solve. ;-D

and why is there a hidden, unused close button in the dropdown menu?

Interesting, and it's functional too. I was actually going to suggest to try adding something like that, but that makes it a whole lot easier to experiment…

but then there is still the issue that if you scroll down the long list of labels you have to scroll up again to get back to the article …

You could add an overflow-y: scroll of some sort I suppose, but it should surely be inside that media query. :-)

no that same issue exists on desktop aka outside that media query …

I was waiting for something like labels for a long time … to categorize my 300+ Favorites i've added 36 labels now … thats a long list … often longer than 2 articles … on some twitter rss feeds even as long as 4 entries

no that same issue exists on desktop aka outside that media query …

I suppose we'll have to agree to disagree. I don't see it as an issue on either platform. On the contrary, I think Gmail is somewhat suboptimal (to put it diplomatically) for basically using the proposed method. ;-)

But! The tag thing does open to the bottom, whereas if you open your context menu at the bottom of your screen it goes up instead. A little JS could provide a negative offset?

Yes we will probably have to agree to disagree …
But In my opinion it's not userfriendly if you have to scroll up & down to compare the content to potentially fitting labels:

And by scrolling the article while scrolling the labels you easier loose the overview over the article
(well perhaps not in tweets)

Although i personally don't use Gmail and a lot of stuff google does is bad … i don't see whats not ok in your screenshots … i'd even say … yes, a searchbar: let's filter the list below if you start typing a new label … maybe the label you want to create already exists in similar form

The principle is fine. Outlook online isn't hugely inferior to Outlook desktop (in this particular way; of course it is). At the same time, I always enjoy how easily I can go through FreshRSS's equivalent list by merely pressing page up and down instead of having to scroll on some particular section of the screen.

This is alright, note how it doesn't randomly cut out a big slice of space like Gmail does:

Okay:

But Outlook's online category management, for instance, utterly unusable if you add more, very disappointing and very Gmail-esque:

i'd even say … yes, a searchbar: let's filter the list below if you start typing a new label … maybe the label you want to create already exists in similar form

Yes, it's a good addition. The problem is that realistically speaking it's the only way of interacting with it. It's just too small otherwise. Like various bizarrely unresizable dialogs in Windows. Most recently I installed new AMD drivers for my GPU and the end user license agreement could be resized neither in window nor font size, nor could it be copied. Making a window resizable is one tiny little flag, but ooooh no, perish the though that someone reads it.

Anyway, back to menus and such, on real desktop applications you get functionality from keys like Home and End. Outlook 365 replicates this. Gmail doesn't.

compare the content to potentially fitting labels:

Interesting use case! I hadn't thought of that.

Setting aside the discussion on menus in general, I really do think that at its best this change wouldn't mess up the other menus too badly while they're better left without. The labels menu seems to be a special case. The application of the scrolling principle can be made generalized, like class="dropdown-menu dropdown-menu-scrollable".

It could also be shorter on thinner windows (so as to cover up less of the content) than on wider ones.

You made a convincing argument that it might be okay for the labels menu not to take up as many pixels as possible, but my biggest objection is to the indiscriminate application of this principle.

Let's say we want all menus to be scrollable. Most menus should take up as much space as they possibly can. 100vh-some padding and stuff. Then there may be menus where that doesn't apply, although like I said before, I think the problem is just that it doesn't open with a negative offset. :-)

I have not followed everything. What is the status of this PR, @Frenzie ?

Not quite ready yet I'd say. @romibi could you perhaps refactor it slightly with the dropdown-menu-scrollable (or something akin to that) to limit it to the filter menu? :-)

Wasn't sure if you wanted to do it …
… is this ok?

Lgtm, thanks!

Thanks @romibi 👍
Merged in /dev