The dimmer profile links are intentional since 99% of the time when you go there you are there to read your notifications, not there to visit your profile, bookmarks, direct link to messages outside the context of a notification, or profile settings.
Also @kuro categories is a heading there.
Well, yes. I think thats what I wanted to express. Though while it might be intented as a heading it looks like any other link above it, has the same hover effect as any other link above it and actually links as any other link above it.
What I am trying to get across is that right now it kinda looks like somebody just typed in the hr too early as it fits way better with the stuff above it then the things in its section.
If you change the style of that heading, I assume it would become clearer.
I am not radically forcing you to change it, though. It is merely a suggestion.
Maybe, instead of the header link above, an āAll Categoriesā link below?
Iām not sure itās required. Those are clearly categories and the other sections donāt have headings.
Yes, but how do you get to the /categories page from hamburger now?
Oops.
Add another entry thatās styled like the rest called āallā or āall categoriesā?
Or something like I posted a few back up-topic?
I think weāre done here.
No that seems wrong too.
https://github.com/discourse/discourse/commit/49096e5801ef5b262dfe1c4356f567d575902f9a
Hereās something a little nasty I found. This surfaced with the new 
(at least, I did not recall seing it earlier):
The style for .d-header .icons .unread-private-messages is specified as left: 82px - thatās fine as long as there are no other icons in the top right. If you add a plugin that uses the plugin outlet to inject another icon, your notifications start to wander around like this:
which is highly confusing right now, but will completely break with the next icon. I suggest to drop the position: absolute in favor of relative positioning - the badge <a> tag is within the <li>, so there is no structural problem here.
Moving the Akismet link was surprisingly tough since it uses an outlet that has been moved. I added a backwards compatibility layer to re-wire outlets, and it seems to be working. Deploying shortly.
Hey, I was the one who brought it up and you argued with loopback0 and RaceProUK.
At least let me pitch something before locking this conversation-path up, please.
See, I am really minimalistic in some ways. And while you can probably style it better, for me a simple
text-align:center on that link makes a huge difference.
Filed Under: If you donāt like it, feel free to simply dismiss it or tell me why you think this is a bad idea. 
Because you should rarely center anything 
Iām not sure that there is any other element in Discourse I can think of that is centered.
The new menus still have some problems on Android 5 and Chrome (tested on my Nexus 5). They are a little bit too high.
And itās impossible to scroll to the bottom of those menus. They always jump up a little bit and start scrolling the topic list in the background. Hereās a screenshot in landscape mode where I tried scrolling to the bottom of the menuā¦
Would it be possible to stop propagating scroll events to parent elements if the element that receives the scroll event has scrollbars? I have a similar problem on desktop when I scroll in the preview while creating a post. It always starts scrolling the visible posts whenever I reach the top or bottom of the preview.
Offtopic: Bonus points if scrolling could be disabled while modal windows are shown.
Same on iPhone chrome, iPhone safari is fine except for the real weird hover effect
One more thing: Clicking on the Discourse logo in the header doesnāt close the Hamburger and profile menus. Iām quite sure that this used to work.
crazy cool! 
The problem with not being able to scroll to the bottom of the content seems to come from $panelBody.height('100%') in menu-panel.js.es6 - that is setting the height to 100% of the content. The result of that is that some of the content may occur outside of the window. Subtracting the header height from the window height and setting $panelBody to that seems to solve the problem let panelHeight = $(window).height() - 55;
edit - this is wrong. There are a few things going on here, but this isnāt it.
