Page MenuHomePhabricator

Allow CSS styling of new notifications without JavaScript
Closed, ResolvedPublic

Description

Author: 7rt1j

Description:
MediaWiki 1.22wmf2 on the English Wikipedia, Extension:Echo
(Bug added at the suggestion of [[User:MZMcBride]]; see http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Allow_CSS_customisation_of_.22.281.29.22.)

I had the new notification indicator "(1)" at the top of my browser on Wikipedia for several hours without realising it. Hence I wanted to do something to make it more prominent; my first thought was user CSS. However, I looked at the HTML source and couldn't see a class= or id= to indicate new notifications.

[[User:Edokter]] told me that JavaScript on the English Wikipedia adds a "mw-badge-important" class after the page has loaded. However, I browse with scripts disabled so this isn't much use to me.

Hence, I am asking that the "mw-badge-important" class is added to the HTML output by Echo, rather than being added later by client-side JavaScript. This should be possible since whether there are new notifications is known when MediaWiki serves the page.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Allow_CSS_customisation_of_.22.281.29.22

Details

Reference
bz48165

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:44 AM
bzimport set Reference to bz48165.

I'm not really sure this is possible without making changes to MediaWiki core. This text is sent to MediaWiki from a hook, but MediaWiki later escapes it (SkinTemplate::makeLink - "$html = htmlspecialchars( $text );") so we can't add HTML to the text without it being shown as plain text.

7rt1j wrote:

For my purposes, I would be satisfied with a <div id="mw-newnotifications"></div> anywhere near the top of the page. I could then use the "content" CSS property along with the :before or :after selector to add a message of my own, along with formatting to make it stand out.

(In reply to comment #1)

I'm not really sure this is possible without making changes to MediaWiki
core.
This text is sent to MediaWiki from a hook, but MediaWiki later escapes it
(SkinTemplate::makeLink - "$html = htmlspecialchars( $text );") so we can't
add HTML to the text without it being shown as plain text.

You're right, but we should indeed change that. The impact of adding the mark-up with JavaScript isn't just that you don't get the enhanced UI unless you have a more modern browser: it's also the underlying reason for a FOUC (flash of unstyled content), which appears even in JS-enabled browsers.

Related URL: https://gerrit.wikimedia.org/r/63256 (Gerrit Change I01c81ad70a6029042cf5873b912f5d9343e88516)

Alex is right. That particular class can not be easily added on the server. This is because Echo doesn't just add a class with JavaScript. It uses a module called jquery.badge (https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/jquery/jquery.badge.js;hb=HEAD) to modify and style the HTML.

However, the above change introduces two classes, 'echo-no-unread-notifications' and 'mw-echo-unread-notifications' that are added on the server. Neither jquery.badge nor the existing Echo client-side code removes them, so they are present with and without JavaScript.

Alex pointed out on the Gerrit change that it would be useful to provide styling (using the proposed classes from 63256 above) when JavaScript is disabled.

Do people have any suggestions for this? I don't think it should be the same as the jQuery badge styling, because the UX is necessarily different without JavaScript, and it would get out sync with jQuery badge proper.

A simple idea is to bold it if there are unread notifications, like many email programs do for a folder.

7rt1j wrote:

The link already appears in bold when I visit [[Special:Notifications]] (using the Monobook skin; this doesn't apply to Vector). To avoid the same styling being used to mean different things, I'd suggest avoiding the use of bold unless it is combined with other styling. (The use of bold to indicate the page I'm on has taught me to ignore any bold on the top line.)

Changing the colours is another simple idea, which should be sufficient (warm colours are probably best for getting attention).

Another idea is to show an icon beside the number (perhaps something like http://upload.wikimedia.org/wikipedia/commons/thumb/e/e0/Icone_information_noir_rouge.svg/18px-Icone_information_noir_rouge.svg.png, possibly with different colours).

As of today, the Echo notification extension includes it's own talk page message alert. You should see this as an orange highlight around the Talk page link which changes to say "Talk: You have new messages" whenever a change has been made to your talk page. You can override the styling for this in your common.css. If you want to turn this alert off, go to your notification preferences and uncheck the box at the bottom. If you want to enable an alert similar to the old "Orange bar of doom", go to the gadget preferences and turn on the "Display a floating alert when I have new talk page messages" option there. There are also a few user scripts, such as User:Writ Keeper/Scripts/orangeBar.js, that do similar things.

Let me know if anything else is needed to resolve this bug.

Kaldari replied on the Gerrit saying there should not be any built-in styling included for now. I'm fine with that, but I do have thoughts if other people think there needs to be no-JS styles right now.

Related URL: https://gerrit.wikimedia.org/r/63993 (Gerrit Change Ie85d66afd5181d487d0bb2776ae14b121ea50d88)

I just committed a change that takes the badge out of JS completely. Let me know what you think of this idea. It also fixes bug 48001.

Sounds fine to me.

The only down-side is it's more work if someone wants to make another badge that works the same way. I don't know how likely that really is though, currently.

7rt1j wrote:

This change is deployed and working on the English Wikipedia (and has been for a while now). The class "mw-echo-unread-notifications" is now added when I have unread notifications.

I'm happy for this bug to be resolved as FIXED. Or is there something else that needs doing before this bug should be marked resolved?

Thanks for the heads up. Indeed, it's fixed.