Change 304584 had a related patch set uploaded (by Catrope):
Tweak badge styles

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

Change 304584 merged by jenkins-bot:
Tweak badge styles

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

The changes have been made and they are in UI:
top: 9px;
left: 55%;
font-size: 0.9em;

vs previously implemented

top: 10px;
left: 50%;
font-size: 0.8em;

However, there are not much visual differences, in my opinion (all screenshots are made in full screen mode, 100% scale):

@Pginer-WMF and @jmatazzoni: 99+ Looks better, in terms of the space around, if font-size: 0.8em; :

Compare with font-size: 0.9em;

The main problem seems to be that the counter in the badge is not considered when the layout is adjusted for the elements in the personal toolbar.

Keeping a fixed separation that works well for all possible lengths of the badge seems hard: too much space will make notification icons to feel too far apart when there is no badge and too few space will cause overlaps.

If it is not possible to make enough space for the badge we could adjust the degree it overlaps with the icon (the "left: 55%" CSS rule). One option is to increase the overlap in general (e.g., changing it back to left: 50%), but that won't get much extra room. Another option is to treat the "99+" case specially, and only in that case allow a bigger overlap (e.g., "left: 35%"). This will cover a bigger part of the icon, but that should not be a big discoverability problem for users that have reach that volume of notifications.

In T142454#2598085, @Pginer-WMF wrote:

The main problem seems to be that the counter in the badge is not considered when the layout is adjusted for the elements in the personal toolbar.

Keeping a fixed separation that works well for all possible lengths of the badge seems hard: too much space will make notification icons to feel too far apart when there is no badge and too few space will cause overlaps.

If it is not possible to make enough space for the badge

It's possible to do this, and we even got it working, but it causes a problem: if you have the popup open and mark a notification as read, the number in the badge changes. If it changes from e.g. 10 to 9, the width of the badge shrinks, and so the badge (along with everything to the left of it) moves to the right. The popup is anchored to the badge, so it moves to the right too. So the net effect is that you clicked a button, and in response to that click the button moved away from under your mouse.

You can try this out yourself by setting width: auto; on the <a> in the badge (a.mw-echo-notifications-badge) and position: relative; left: 5px; on the :after of that <a>. You can also fake the number on the badge by changing the data-counter-text attribute.

Thanks for the clarification @Catrope. We definitely don't want the panel to shake as you mark notifications as read. Do you think there will be issues in supporting the other alternative I described (adjusting the "left" overlap percentage when the counter is "99+")?

Adjusting the left percentage won't cause this issue and should be doable. Figuring out that we are in the 99+ case in software might be a bit tricky though (because of translations and different numeral systems), so maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

If anyone were to ask me, I'd advise just putting in some extra space next to the trays to accommodate the worst case and live with it looking extra-spacey when the counters are at low numbers. Would that be wrong?

Anyway, @Etonkovidova, I'm seeing this in the product review column. But I don't see where any changes were made. So I'm not sure what is being asked of me. @Catrope, did you settle on an approach here? Should I put it back in Dev?

In T142454#2704619, @jmatazzoni wrote:

If anyone were to ask me, I'd advise just putting in some extra space next to the trays to accommodate the worst case and live with it looking extra-spacey when the counters are at low numbers. Would that be wrong?

I'd prefer to fix the case where there is a problem ("99+") without generating a problem for more common cases (according to our data, 99% of the users have 5 or less unread notifications).

In the comments above I proposed the following: treat the "99+" case specially, and only in that case allow a bigger overlap with the badge (e.g., "left: 35%"). this makes the badge to act as if the text was right aligned (expanding to the left when needed instead of taking additional space to the right).

The comment form Roan where he indicates that "Figuring out that we are in the 99+ case in software might be a bit tricky though" is a bit confusing to me because is the software the one writing "99+" in the first place so I expected there should be a more elegant way to know the number of notifications a user has beyond parsing the badge text. Some possible ideas:

• Add a specific class when the "+99" text is computed, and base the CSS rule to adjust the overlap on such class.
• Base the decision in the width of the badge instead of the content. If the badge is "too wide" we increase the overlap.

Based on @Etonkovidova's screenshots above, it looks like changes were made but this issue is not fixed. @Catrope suggested:

maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

@SBisson, you worked on this. Would that solution be complicated? Would it work? As Pau points out, the 99+ case is pretty rare, so I'm moving this off the Q2 board (to Triage/Hot). But I'd like to fix it if we can. Stephane, if you think this will be easy to fix, go ahead and move it back to Q2.

In T142454#2873962, @jmatazzoni wrote:

Based on @Etonkovidova's screenshots above, it looks like changes were made but this issue is not fixed. @Catrope suggested:

maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

@SBisson, you worked on this. Would that solution be complicated? Would it work? As Pau points out, the 99+ case is pretty rare, so I'm moving this off the Q2 board (to Triage/Hot). But I'd like to fix it if we can. Stephane, if you think this will be easy to fix, go ahead and move it back to Q2.

I've never worked on it but I can check what such a fix would look like.

I wrote down what this would look like (it's a few simple CSS changes but I don't remember what they are), but not in a very useful place. You should be able to find it by looking through my (Roan Kattouw (WMF)'s) edits on [[WP:VPT]] on enwiki

@jmatazzoni, @Catrope, @SBisson, In case it was lost in the comments above, I'll mention it again:

I'd prefer to fix the case where there is a problem ("99+") without generating a problem for more common cases (according to our data, 99% of the users have 5 or less unread notifications).

In the comments above I proposed the following: treat the "99+" case specially, and only in that case allow a bigger overlap with the badge (e.g., "left: 35%"). this makes the badge to act as if the text was right aligned (expanding to the left when needed instead of taking additional space to the right).

The comment form Roan (T142454#2602121) where he indicates that "Figuring out that we are in the 99+ case in software might be a bit tricky though" is a bit confusing to me because is the software the one writing "99+" in the first place so I expected there should be a more elegant way to know the number of notifications a user has beyond parsing the badge text. Some possible ideas:

• Add a specific class when the "+99" text is computed, and base the CSS rule to adjust the overlap on such class.
• Base the decision in the width of the badge instead of the content. If the badge is "too wide" we increase the overlap.

Is any of these a viable solution for the specific "+99" case?

Change 328404 had a related patch set uploaded (by Sbisson):
Adjust unread counter position based on length

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

Change 328404 merged by jenkins-bot:
Adjust unread counter position based on length

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

Checked in betalabs - IE11, Windows 7, Chrome 54. FF 50, Safari 10.

@Pginer-WMF, please review the screenshots.

Added the screenshot for cawiki (to check the case with 'D') - looks ok.

Interestingly, that in monobook skin, two-digit numbers cover the icons almost completely. This is a slight regression - look at the monobook screenshot in the ticket description. Also, I added tabs 'unwatch' to see how new layout fits for users with many tabs.

In T142454#2895372, @Etonkovidova wrote:

@Pginer-WMF, please review the screenshots.

Good. The fix seems to avoid the overlap (except for the Monobook case, which can have a separate ticket).

Thx @Pginer-WMF . I filed T153976: [minor-regression] Notification counter '99+' overlaps mw-echo-notifications-badge

Change 328730 had a related patch set uploaded (by Sbisson):
Use the right counter for the right badge

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

Change 328730 merged by jenkins-bot:
Use the right counter for the right badge

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