Page MenuHomePhabricator

Create Mediawiki:Group-user.css to allow content differentiation for logged-in editors versus readers
Closed, ResolvedPublic

Description

Presently, Mediawiki provides the system messages:

Mediawiki:Group-sysop.css
Mediawiki:Group-sysop.js
Mediawiki:Group-checkuser.css
Mediawiki:Group-checkuser.js

etc.

Such that most user classes can have specific CSS and JS associated with them.

See also: http://www.mediawiki.org/wiki/Manual:User_group_CSS_and_Javascript

As written, the code explicitly excludes the ability to manage content based on membership in the "user" group of logged-in editors. Is there a good reason for this?

If there is not a specific reason for prohibiting

Mediawiki:Group-user.css
Mediawiki:Group-user.js

Then I would suggest that they should be added.

Such a mechanism would provide a natural way to differentiate some content for logged-in editors vs. readers. For example, many message boxes and error messages can be rather cryptic or unhelpful for readers, and it may make sense to provide readers with a more general explanatory statement while showing editors a different and more specific "how do I fix this" kind of message. Obviously any such differentiation would have to be mindful of the fact that IPs can be editors too, but I think decisions about if/when message differentiation is appropriate is more a community issue than a technical one.

So, if there isn't a technical reason that would block this, can we add "user" to the set of classes that can have class-wide CSS and JS pages?


Version: 1.22.0
Severity: enhancement
Whiteboard: gci2013
URL: https://www.google-melange.com/gci/task/view/google/gci2013/5906739270516736
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57986
https://bugzilla.wikimedia.org/show_bug.cgi?id=13242

Details

Reference
bz47812

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz47812.

I think this is trivial; we already have Group-autoconfirmed.css.

wikimedia wrote:

I see a need in MediaWiki:Group-user.css/js since autoconfirmed is not granted from the user's registration in some wikis.
I've tried to do some CSS for non-autoconfirmed but logged-in users in MediaWiki.org and was just wondering about that behaviour.

Copying Happy-melon on this bug in case he'd like to weigh in here (he authored r82285).

happy.melon.wiki wrote:

Obviously any such differentiation would have to be mindful of the fact that
IPs can be editors too, but I think decisions about if/when message
differentiation is appropriate is more a community issue than a technical
one.

My reason for not originally implementing Group-user is basically a personal philosophy, that I do not trust wiki communities (enwiki especially) to *actually* remember the point above. "Logged in verses logged out" is not the same as "readers verses editors", and as such, I felt (and still feel) that this feature had *only* misuses, not legitimate uses. If this was made available as the only way of cleanly leveraging one of these distinctions, it would be used as "well this is the best we've got", but it's use would actually be quite detrimental to the wiki's openness.

  • Bug 57486 has been marked as a duplicate of this bug. ***

(In reply to comment #5)

My reason for not originally implementing Group-user is basically a personal
philosophy, that I do not trust wiki communities (enwiki especially) to
*actually* remember the point above. "Logged in verses logged out" is
not
the same as "readers verses editors", and as such, I felt (and still feel)
that
this feature had *only* misuses, not legitimate uses. If this was made
available as the only way of cleanly leveraging one of these distinctions, it
would be used as "well this is the best we've got", but it's use would
actually
be quite detrimental to the wiki's openness.

Agreed, some people probably will misuse it. That said, I don't think we should limit the software in a way like this. If you have a fishbowl wiki, the distinction between readers and editors *is* whether you're logged in or not.

happy.melon.wiki wrote:

(In reply to comment #7)

Agreed, some people probably will misuse it. That said, I don't think we
should limit the software in a way like this.

Are you saying that because you believe that the potential for legitimate use outweighs the potential for misuse in this instance, or because you think as a general principle we should *never* not implement features because they have the potential to be misused? If so, I don't think that's a very realistic position. The damage to new editor recruitment that creating a UI distinction between logged-in and logged-out would do is creeping and insidious (user makes first tentative step towards editing, is suddenly attacked by a barrage of weird new functionality; conversely reader does not see any of the invitations to edit, so does not make first step).

If you have a fishbowl wiki, the

distinction between readers and editors *is* whether you're logged in or not.

This has never been an issue that's particularly hard to work around; the main benefit to having it done 'formally' is mainly proper caching via ResourceLoader, and reduction of redundant code load. Both of which are less important on a fishbowl wiki, which will generally be smaller.

tehalmightyscimonster wrote:

I've taken up this task in the Code-in, and should have a working patch very soon.

Change 99434 had a related patch set uploaded by Scimonster:
Add group-user-css/js messages.

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

One use-case I ran into myself is scripts which use custom preferences (see https://www.mediawiki.org/wiki/API:Options#Changing_options) – these can sometimes only be reasonably ran for registered users.

Change 99434 had a related patch set uploaded by Scimonster:
Unblacklist group-user-css/js

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

Change 99434 merged by jenkins-bot:
Unblacklist group-specific JS/CSS for the user group

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

Done by Scimonster as a GCI task. Thanks!

I updated the documentation at [[mw:Manual:User group CSS and Javascript]].